[Qemu-devel] Changing the QEMU svn VERSION string

[Qemu-devel] 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

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

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

[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

[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

[Qemu-devel] 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: [Qemu-devel] Changing the QEMU svn VERSION string

[Andreas Färber]

Hi,

On the topic of QEMU help output, it still reads:
Copyright (c) 2003-2008 Fabrice Bellard

Since the code was last modified in 2009, I feel that should be  
reflected in some copyright statement.
Given that iirc Fabrice has not contributed code this year, I see two  
options:

Copyright (c) 2003-2009 Fabrice Bellard and contributors

Or if we want to stick with one maintainer's name only:

Copyright (c) 2003-2008 Fabrice Bellard
Copyright (c) 2008-2009 Anthony Liguori

Andreas


Am 07.04.2009 um 04:37 schrieb 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
>
>

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

[M. Warner Losh]

In message: <264E220E-78B4-4A46-93E3-B896192058EB@web.de>
            Andreas_Färber <andreas.faerber@web.de> writes:
: Hi,
: 
: On the topic of QEMU help output, it still reads:
: Copyright (c) 2003-2008 Fabrice Bellard
: 
: Since the code was last modified in 2009, I feel that should be  
: reflected in some copyright statement.

Likely.

: Given that iirc Fabrice has not contributed code this year, I see two  
: options:
: 
: Copyright (c) 2003-2009 Fabrice Bellard and contributors
: 
: Or if we want to stick with one maintainer's name only:
: 
: Copyright (c) 2003-2008 Fabrice Bellard
: Copyright (c) 2008-2009 Anthony Liguori

What purpose is this copyright notice?  Is it to notify users of the
collection copyright (eg, the gluing together of everything)?  In that
case, the above is fine.  If it is supposed to be for everybody's
individual contributions, then none of the above are sufficient (or
required).  However, it likely would be good to include a contributors
page.  I haven't reviewed all the licenses in all the files in the
system, but it never hurts to have a file that acknowledges all the
copyrights in a central place.

Unlike trademarks, you can't say "Copyright by a bunch of folks"
That's not valid copyright notice, and that's what the "and
contributors" does....

My recommendation would be to go with the second form.

Warner



: Am 07.04.2009 um 04:37 schrieb 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
: >
: >
: 
: 
: 
: 

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

[Andreas Färber]

Am 07.04.2009 um 18:29 schrieb M. Warner Losh:

> In message: <264E220E-78B4-4A46-93E3-B896192058EB@web.de>
>            Andreas_Färber <andreas.faerber@web.de> writes:
> : Hi,
> :
> : On the topic of QEMU help output, it still reads:
> : Copyright (c) 2003-2008 Fabrice Bellard
> :
> : Since the code was last modified in 2009, I feel that should be
> : reflected in some copyright statement.
[...]
> What purpose is this copyright notice?  Is it to notify users of the
> collection copyright (eg, the gluing together of everything)?

 From my POV, its main purpose is indicating to the casual user the  
time span the software was developed in (rather than the date of  
compilation).

In my country, there is no "copyright" and I do own the IPR to my  
patches independently of such a notice.
I believe the copyright notice may have more significance in the US  
but IANAL.

Andreas

> In that
> case, the above is fine.  If it is supposed to be for everybody's
> individual contributions, then none of the above are sufficient (or
> required).  However, it likely would be good to include a contributors
> page.  I haven't reviewed all the licenses in all the files in the
> system, but it never hurts to have a file that acknowledges all the
> copyrights in a central place.
>
> Unlike trademarks, you can't say "Copyright by a bunch of folks"
> That's not valid copyright notice, and that's what the "and
> contributors" does....
>
> My recommendation would be to go with the second form.
>
> Warner