[virt-tools-list] virt-manager gtk3 and virtinst merge now on master branch

[Cole Robinson]

On 04/04/2013 09:31 AM, Gene Czarcinski wrote:
> On 04/03/2013 08:40 PM, Cole Robinson wrote:
>> The virt-manager gtk3.2 branch has now become virt-manager master. Previous
>> master is now on a 0.9-maint branch, if we ever want to do bug fix releases of
>> the old 0.9 series.
>>
>> Since virtinst has been merged with virt-manager, the virtinst master branch
>> has been emptied except for a simple readme. There's now a 0.6-maint branch
>> which contains the previous virtinst master.
>>
>> So the next virt-manager release will definitely be gtk3 based!
> So, this will now be toe basis for future releases.  Any idea as to whether
> this will be 0.10.0 or 1.0.0?  Regardless, I have a couple of
> suggestions/comments.
> 

1.0 makes sense given the quantity of change, but then again it comes with
increased fanfare so it will depend on how confident I am about the quality of
release. Maybe 1.0 could be python3 port and snapshot UI.

> 1. virtcli/clicongfig.__version__ is still 0.9.4
> 
> 2.  I prefer and suggest that, instead of this hardcoded value for version
> which requires a git-commit, tags be used.  Therefore, I suggest that such a
> tag be used now the set the base.
> 
> 3.  Add a "modifier" to indicate what the current release-marker tag is.  This
> could be something like 0.10.0.0, 0.10.0.1, 0.10.0.2, ... or 0.10.0-dev1,
> 0.10.0-dev2, and 0.10.0-rc1, 0.10.0-rc2, ... to provide more info about that
> the current "HEAD" is/means.  Then an tag or fixed version-id of 0.10.0 or
> 0.10.1 would be the "release" version-id.  BTW, my versioning patch strips off
> anything prefix/postfix added the the version-id with a "-".
> 

While I understand that this would make the __version__ most accurately
reflect the state of the code, I just don't see the benefit. Certainly not for
complicating the build system.

> BTW, maybe the version-id for this new development branch should be "0.9.99"
> which then could become "0.10.0" upon release.  An alternative is the
> development branch being something like "0.99.0" which then could result in
> "1.0.0" as the release-id.

I'm happy to do something like this: like once a release goes out the door,
say 0.9.5, the development branch becomes 0.9.5.500 or something. But I
haven't thought much about it.

> 
> 4. One of the objectives with my versioning patch is to implement unique
> version identifiers to support snapshots.  In my v1 of the patch, if the
> version_id is a "release" version-id, then only the version-id is used. 
> Otherwise a snapshot identifier of ".gityyyymmdd" is used.  Based on what I
> saw in autobuild.sh, maybe I should use ".git<now-seconds>.  This release-id
> or snapshot-id is used in the tarball name as well as being set for the
> "@VERSION@" in virt-manager.spec ... comments/suggestions?
> 

I'm not a fan of the hardcoded version in virt-manager.spec which is currently
the case, that was really a temporary measure I added just a couple weeks back
to facilitate the build system overhaul.

But I also don't see why we should cram this git machinery into the build
system. If you want to make regular RPM builds of the source code, you can a)
use autobuild since it's already more or less supported or b) role your system
which should really be trivial.

Have the version be tied with git just sounds like overcomplication for a
narrow usecase, and means that I have to test python setup.py rpm from both a
git checkout _and_ a release tarball to make sure we are handling both cases
correctly, since they will be different code paths.

Thanks,
Cole