Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
