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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/10/2009 12:19 PM, Mark McLoughlin wrote:
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 :-)

I'm not Anthony.

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

Yeah.  You still couldn't distinguish among different snapshots.

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

Logically it needs to work before starting a VM, so a command line option is more appropriate.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux