9:37 p.m.
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
3:10 a.m.
New subject: [libvirt] Re: [Qemu-devel] 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.
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
4:03 a.m.
New subject: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
8:52 a.m.
New subject: [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
12:13 p.m.
New subject: [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
1:35 a.m.
New subject: [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
12:58 p.m.
New subject: [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
5:36 p.m.
New subject: [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
8:13 a.m.
New subject: [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 majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
8:56 a.m.
New subject: [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
4:04 a.m.
New subject: [libvirt] Re: Changing the QEMU svn VERSION string
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 :|
5710
days inactive
5711
days old
10 comments
7 participants
participants (7)
-
Anthony Liguori -
Daniel Jacobowitz -
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Jamie Lokier -
Paul Brook