[libvirt] Changing the QEMU svn VERSION string
Hi, I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing. I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that. Being the nice guy I am, I thought I would check that this didn't make libvirt go bonkers :-) This is the relevant detection code in libvirt: if (sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u)", &major, &minor, µ, &kvm_version) != 4) kvm_version = 0; if (!kvm_version && sscanf(help, "QEMU PC emulator version u.%u.%u", &major, &minor, µ) != 3) goto cleanup2; If I change SVN to 0.11.0-devel, that's going to break the KVM string although the QEMU string will continue to work. Avi could potentially carry a patch to keep it 0.10.x and since kvm-%u will be used to identify features, that should keep things working. Anyone have any objections/suggestions? Regards, Anthony Liguori
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that.
Maybe 0.10.99 ? Or 0.10.90, leaving the door open to number the 0.11 beta / rc versions (if any) 0.10.9{1,2,3}? cheers, Gerd
On Tue, Apr 07, 2009 at 10:10:20AM +0200, Gerd Hoffmann wrote:
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that.
Maybe 0.10.99 ? Or 0.10.90, leaving the door open to number the 0.11 beta / rc versions (if any) 0.10.9{1,2,3}?
Concur, we have no good way of representing something like 0.11.0-devel from an rpm Name-Version-Release and be sure it won't break down the road if we change our mind on the final naming scheme, while something like 0.10.90 convey the intent while still being compatible with the existing numbering scheme (plus it eventually forces you to release the new version ;-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Daniel Veillard wrote:
On Tue, Apr 07, 2009 at 10:10:20AM +0200, Gerd Hoffmann wrote:
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that.
Maybe 0.10.99 ? Or 0.10.90, leaving the door open to number the 0.11 beta / rc versions (if any) 0.10.9{1,2,3}?
Concur, we have no good way of representing something like 0.11.0-devel from an rpm Name-Version-Release and be sure it won't break down the road if we change our mind on the final naming scheme, while something like 0.10.90 convey the intent while still being compatible with the existing numbering scheme (plus it eventually forces you to release the new version ;-)
I think that's going to lead to even more confusion. While I'm inclined to not greatly mind 0.10.99 for the development tree, when we do release candidates for the next release, it's going to be 0.11.0-rc1. I don't expect RPMs to ever be created from non-release versions of QEMU provided we stick to our plan of frequent releases. I still think libvirt should work with versions of QEMU/KVM built from svn/git though. I think the only way to do that is for libvirt to relax their version checks to accommodate suffixes in the form major.minor.stable-foo. Regards, Anthony Liguori
Daniel
Anthony Liguori wrote:
I still think libvirt should work with versions of QEMU/KVM built from svn/git though. I think the only way to do that is for libvirt to relax their version checks to accommodate suffixes in the form major.minor.stable-foo.
Ok, but try to stick to a well-defined rule about what suffix means "later" or "earlier". In package managers, "1.2.3-rc1" is typically seen as a later version than "1.2.3" purely due to syntax. If you're consistently meaning "0.11.0-rc1" is earlier than "0.11.0" (final), that might need to be encoded in libvirt and other wrappers, if they have any fine-grained version sensistivity such as command line changes or bug workarounds. The Linux kernel was guilty of mixing up later and earlier version suffixes like this. With Linux this is a bit more important because it changes a lot between versions, so some apps do need fine-grained version checks to workaround bugs or avoid buggy features. Maybe that won't even happen with QEMU and libvirt working together. -- Jamie
On 04/07/09 19:13, Jamie Lokier wrote:
Anthony Liguori wrote:
I still think libvirt should work with versions of QEMU/KVM built from svn/git though. I think the only way to do that is for libvirt to relax their version checks to accommodate suffixes in the form major.minor.stable-foo.
Ok, but try to stick to a well-defined rule about what suffix means "later" or "earlier". In package managers, "1.2.3-rc1" is typically seen as a later version than "1.2.3" purely due to syntax.
Fedora typically handles this using a leading zero in the 'release' component for pre-final versions, like this: app-1.2.3-0.rc1.fc11 (rc/beta) and app-1.2.3-1.fc11 (final). Likewise for snapshots: app-1.2.3-0.svn${date}.fc11
If you're consistently meaning "0.11.0-rc1" is earlier than "0.11.0" (final), that might need to be encoded in libvirt and other wrappers, if they have any fine-grained version sensistivity such as command line changes or bug workarounds.
libvirt scans the help text to figure which features are present (checking for as -drive and -uuid cmd line switches for example). cheers, Gerd
On Tue, Apr 07, 2009 at 08:52:46AM -0500, Anthony Liguori wrote:
I think that's going to lead to even more confusion. While I'm inclined to not greatly mind 0.10.99 for the development tree, when we do release candidates for the next release, it's going to be 0.11.0-rc1. I don't expect RPMs to ever be created from non-release versions of QEMU provided we stick to our plan of frequent releases.
FWIW, GDB uses 6.8.50 (devel branch), 6.8.90 (release branch), 6.8.91 (rc1). That's worked out well for us. -- Daniel Jacobowitz CodeSourcery
On Tuesday 07 April 2009, Daniel Jacobowitz wrote:
On Tue, Apr 07, 2009 at 08:52:46AM -0500, Anthony Liguori wrote:
I think that's going to lead to even more confusion. While I'm inclined to not greatly mind 0.10.99 for the development tree, when we do release candidates for the next release, it's going to be 0.11.0-rc1. I don't expect RPMs to ever be created from non-release versions of QEMU provided we stick to our plan of frequent releases.
FWIW, GDB uses 6.8.50 (devel branch), 6.8.90 (release branch), 6.8.91 (rc1). That's worked out well for us.
I like this one. I'm extremely sceptical of anything that claims to need a fine grained version number. In practice version numbers for open source projects are fairly arbitrary and meaningless because almost everyone has their own set of patches and backported fixes anyway. Paul
Paul Brook wrote:
On Tuesday 07 April 2009, Daniel Jacobowitz wrote:
On Tue, Apr 07, 2009 at 08:52:46AM -0500, Anthony Liguori wrote:
I think that's going to lead to even more confusion. While I'm inclined to not greatly mind 0.10.99 for the development tree, when we do release candidates for the next release, it's going to be 0.11.0-rc1. I don't expect RPMs to ever be created from non-release versions of QEMU provided we stick to our plan of frequent releases.
FWIW, GDB uses 6.8.50 (devel branch), 6.8.90 (release branch), 6.8.91 (rc1). That's worked out well for us.
I like this one.
So do I. Regards, Anthony Liguori
I'm extremely sceptical of anything that claims to need a fine grained version number. In practice version numbers for open source projects are fairly arbitrary and meaningless because almost everyone has their own set of patches and backported fixes anyway.
Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Brook wrote:
I'm extremely sceptical of anything that claims to need a fine grained version number. In practice version numbers for open source projects are fairly arbitrary and meaningless because almost everyone has their own set of patches and backported fixes anyway.
I find it's needed onlyh when you need to interact with a program and workaround bugs or temporarily broken features, and also when the program gives no other way to determine its features. For some reason, I find kernels are the main thing this matters for... If the help text, some other output, or an API gives enough information for interacting programs to know what to do, that's much better and works with arbitrary patches etc. -- Jamie
On Mon, Apr 06, 2009 at 09:37:55PM -0500, Anthony Liguori wrote:
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that.
Being the nice guy I am, I thought I would check that this didn't make libvirt go bonkers :-) This is the relevant detection code in libvirt:
if (sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u)", &major, &minor, µ, &kvm_version) != 4) kvm_version = 0;
if (!kvm_version && sscanf(help, "QEMU PC emulator version u.%u.%u", &major, &minor, µ) != 3) goto cleanup2;
If I change SVN to 0.11.0-devel, that's going to break the KVM string although the QEMU string will continue to work. Avi could potentially carry a patch to keep it 0.10.x and since kvm-%u will be used to identify features, that should keep things working.
The only things we use the KVM version for are to decide whether migration and vnet_hdr flag for tun devices is supported. These checks are already outdated since 0.10.0 QEMU now has support for migration, and thus needs updating. So if you choose to go with '0.11.0-devel' it won't cause any huge problems for us, and I'll change this code to make it more forgiving of version number string changes in future. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (7)
-
Anthony Liguori -
Daniel Jacobowitz -
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Jamie Lokier -
Paul Brook