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

Hi,

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

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/
[email protected]  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

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

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

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:

In message: <[email protected]>
Andreas_Färber <[email protected]> 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
: >
: >
:
:
:
:

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

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

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

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

libvirt scans the help text to figure which features are present (checking for as -drive and -uuid cmd line switches for example).

cheers,
Gerd

So do I.

Regards,

Anthony Liguori

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

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

[...]

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