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

[Gene Czarcinski]

On 04/13/2013 10:01 AM, Gene Czarcinski wrote:
> 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.
>
>
Never mind.  A whole bunch of poking around with some trial and error 
figured out how to do it.  Now, of course, it is obvious. ;)

It still needs work but the general plan is:

a) keep the pkgversion -> __version__ patch

b) append a "snapshot suffix" to the value of __version__.  This suffix 
will only apply to the sdist-tarball and the rpm derived from that tarball.

Gene