Re: [PATCH]: Always use KVM_VERSION to build version number

[Mark McLoughlin <markmc@redhat.com>]

On Sun, 2009-08-09 at 12:58 +0300, Avi Kivity wrote:
> On 08/07/2009 03:31 PM, Chris Lalancette wrote:
> > Avi,
> >       Trying to use libvirt with development snapshots of qemu-kvm is a bit
> > problematic.  The trouble is that for all development snapshots, the value that
> > gets placed into this string:
> >
> > QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
> >
> > Is always kvm-devel.  That means we can't tell if this is a kvm development
> > snapshot built yesterday, or 6 months ago, which means that in turn we can't
> > tell what features are available.  While we can always tell people building
> > their own qemu to force it by echoing a value into KVM_VERSION, it would be much
> > better if this were done by default.  Something like kvm-88-devel, which would
> > signify that this the development happening after kvm-88, leading towards
> > kvm-89.  Would you accept something like the patch below, which would require
> > you to edit the KVM_VERSION file twice during a release (once right before the
> > release, to change it to kvm-89, and once right after the release to change it
> > back to kvm-89-devel)?
> >
> >    
> 
> This is problematic in two ways.  One is that I am basically guaranteed 
> to forget to edit the file (which is why the release scripts generate 
> the name based on the tag).

Anthony manages to remember to update VERSION :-)

> On fix is to use git describe --match to find out what's the closest 
> release.  But this is still quite bad as it doesn't account for branches 
> and forks.

Or we could drop this kvm snapshot numbering system and just use qemu
VERSION numbering - i.e. qemu-kvm-devel-88 could have been published as
qemu-kvm-0.10.50

> How about adding 'qemu -describe-features' which will output, one line 
> per feature, what's supported (and limits where applicable)?  I 
> understand libvirt already does this for some features using -help; this 
> is simply a formalization of that hack.

Yes, libvirt would much rather not parse -help or use version numbers to
detect whether features are available.

We should revisit the "info capabilities" thing again:

  http://lists.gnu.org/archive/html/qemu-devel/2008-11/msg00767.html

Cheers,
Mark.