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

[Gene Czarcinski]

Based on the previous reaction to changing the version-id, I want to 
keep it small and simple.  My idea of small and simple has been 
implemented and submitted as a set of 5 small patches.  These change the 
default value for cliconfig.__version__ to something more representative 
of a development/pre-release status for whatever the version will be for 
the next big release (non 0.9-maint).  It then adds an option for a 
simple (YYYYMMDD) snapshot id.  Note: no git dependence. If this is 
accepted and incorporated, future patches by me or others can complexify 
the snapshot-id for whatever anyone wants.

More comments below.

On 04/13/2013 01:15 PM, Christophe Fergeau wrote:
> On Sat, Apr 13, 2013 at 10:01:28AM -0400, Gene Czarcinski wrote:
>> 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.
> Iirc, this scrit just outputs a version number on stdin, so while the
> usage instructions are about an autotools based build system, I assume
> it should not be too difficult to adapt it to different needs/build
> systems.
Right now I am just using the date and I can get this suffix in one line 
of python code.
>
>> 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".
>
> I'm not sure what you are trying to get to here... You can
> - tweak the script to understand your tag format
> - replace the hardcoded version string in virtcli/cliconfig.__version__
>    with something that comes from the git-version-gen script
> Oh, or is #2 complicated to do? /me just glanced over the rest of the
> email.
I figured out how to get python-distutils to do what I wanted it to do 
and then the rest was easy.
>
>> 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.
> I basically stopped reading here :) Yeah, if you start considering
> branches, things get harder, but I rather stay with a simple solution
> with known caveats rather than something more complicated/invasive.
My background involves a lot of security related stuff so I try to 
consider what a user might do and not what the used should do. However, 
there is good info in the output of git-describe-tags ... just not 
something you can reliably depend on for a version-id.
>
>> 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.
> Not sure if you are talking about the git-version-gen script, or just
> the built-in git describe command. The git-version-gen script gives
> you a nice version number as soon as your HEAD corresponds to a tag.
>
The big hurdle for using anything related to git is that it usually 
involve tags and while there is a tag set for major releases in 
virt-manager, that is about it.

Some projects such as libvirt use tags for the releases plus for each of 
the release candidates but it also uses autotools so the version depends 
on what is in configure.ac.

Other projects such as dnsmasq make even greater use of tags ... 
releases, release candidates, test releases ... the list is huge.

AFAIK, you cannot set tags with a patch.  Therefore, the 
main/controlling developers of virt-manager will need to decide what, if 
anything, to do about tags.  I believe that the patches I have submitted 
provide more flexibility while not rocking-the-boat (with patches 
applied, do nothing else and nothing changes).

I believe I have spent enough time on this.  I need to get some updates 
done to get what is in virt-manager for the new static-route support 
back in sync with what has been submitted to libvirt.

Gene