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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
