[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [virt-tools-list] [PATCH-v5.5 5/5] virt-manager version-id changes



On 04/12/2013 03:37 PM, Christophe Fergeau wrote:
On Thu, Apr 11, 2013 at 02:01:39PM -0400, Gene Czarcinski wrote:
I think this can be solved by adding an option to sdist or rpm subcommands
that allows temporarily overwriting __version__. Then all the __version__
building logic can be moved to an external script, which just passes the value
to setup.py
Great minds and all that stuff.

This is more or less the approach I thought to look into.  Something
where the default is as it now is but with some means of specifying
a "user version" override when sdist is run.
I haven't followed the conversation closely, hopefully all of this was not
discussed yet ;) The solution you are aluding to sounds a lot like the
git-version-gen script which is used in several projects, see
http://stuff.mit.edu/afs/athena/astaff/project/opssrc/cups/autoconf-2.65/build-aux/git-version-gen
for example.
This is the solution Eric mentioned at the beginning of this thread
https://www.redhat.com/archives/virt-tools-list/2013-April/msg00106.html

The way the versioning is done is:
- if there's a 'vXXXX' tag pointing at the current HEAD, then version is
   XXX
- else version is XXXX.z-hash where XXXX is the most recent tag in the
   current branch, z is the number of commits made since that tag, and
   hash is a short hash for HEAD

This gives you a version number that always increases, even for snapshots
from git.

I like what the referenced script does. Unfortunately, it works with autotools and those have been removed from virt-manager and replaced with python's distutils which has the same or at least similar objectives but is definitely different.

I like using a tag as the basis for "version." Unfortunately, this is a bit difficult. AFAIK, you cannot set a tag via patch and version is set from the value of the hardcoded and git tracked virtcli/cliconfig.__version__ which has the current value of "0.9.4". In addition, the tags which are used to identify the commit which is the base (top level) for a release has the form of RELEASE-0.0.0-1 ... a little string editing gets this to "0.0.0".

While I like the information provided by git-describe--tags, it does not necessarily produce an increasing number. Consider a base with the tag of "0.9.100". Now have two branches off that. The two branches sill likely have different values for commits as well has the commit-id but the relationship is definitively defined and you could desire to replace "0.9.100.19" with "0.9.100.10" (last number is the number of commits). The git-describe--tags information would (IMHO) be good for an internal "version" but not when used for the version-id in a sdist-tarball or an rpm. Right now, I am not going to worry about git-describe--tags and a potention internale version-id.

So, my focus is the version-id for taballs and rpms (that is in the spec file that is part of the tarball.

Right now I am envisioning a "bunch" of small steps the first two of which should be acceptable:

1. For the current master (gtk3.2+), update cliconfig.__version__ to be "0.9.100" to indicate development/prerelease for whatever the next release will be called.

2. Put spec.in back in witjh @VERSION@ and add "my_sdist" class to setup.py. Before running the regular sdist, spec.in is copied to spec with @VERSION@ updated to the value of cliconfig.__version__.

Here is where is starts getting questionable.

3. Add a "pkgversion" keyword to setup.py-configure and, if something is specified, update cliconfig.__version__ to that value during cliconfig initlization. This is a nice to have but the result will be that the pkgversion value is used for everything and not just the sdist-tarball.

The problem is the the setup() kerword "version" is initialized/set long before sdist is called. I do not see how to change it. Furthermore, specifying any version when sdist is run is thus useless.

First of all, I am NOT a python expert or anything like that (think beginner or novice). Therefore, there may be a way to override the methods and I do not understand how to do it.

It appears that [all of this is under "distutils"] sdist uses Command and which, in turn, uses dist. dist has the primary definition for class Distribution but also has this somewhat hidden class DistributionMetadata and it is that last class which defines get_fullname() [name + version]. In the sdist class, there is the make_distribution() method which calls distribution.get_fullname().

Creating a good, acceptable version-id is easy. Getting it used without re-writing a lot of code not so much.

If one of you python experts out there knows how to do the override, I would appreciate any help.

Gene


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]