Changing the QEMU svn VERSION string

Changing the QEMU svn VERSION string

[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.

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, &micro, &kvm_version) != 4)
     kvm_version = 0;

if (!kvm_version && sscanf(help, "QEMU PC emulator version u.%u.%u",
     &major, &minor, &micro) != 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

[libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Gerd Hoffmann]

   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

Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Daniel Veillard]

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/

Re: Changing the QEMU svn VERSION string

[Daniel P. Berrange]

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, &micro, &kvm_version) != 4)
>     kvm_version = 0;
> 
> if (!kvm_version && sscanf(help, "QEMU PC emulator version u.%u.%u",
>     &major, &minor, &micro) != 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 :|

Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Anthony Liguori]

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
>
>   

Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Jamie Lokier]

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

Re: [libvirt] Re: Changing the QEMU svn VERSION string

[Daniel Jacobowitz]

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

Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Paul Brook]

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

Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Gerd Hoffmann]

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

Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Anthony Liguori]

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
>   

Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string

[Jamie Lokier]

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