On Wed, Mar 08, 2017 at 09:26:00AM +0100, Thomas Huth wrote: > > Hi everybody, > > what will be the next version of QEMU after 2.9? Will we go for a 2.10 > (as I've seen it mentioned a couple of times on the mailing list > already), or do we dare to switch to 3.0 instead? > > I personally dislike two-digit minor version numbers like 2.10 since the > non-experienced users sometimes mix it up with 2.1 ... and there have > been a couple of new cool features in the past releases that would > justify a 3.0 now, too, I think.
If we need to debate whether to switch major version numbers, it is a sign we should set out a clearer policy on version numbering :-) AFAIK, QEMU's never documented semantics for changes in the major number part of the version. I don't think the 1.0 or 2.0 releases were particularly significant in what they introduced/changed, as opposed to many of the .x releases. It was a fairly arbitrary decision to bump the major version. libvirt suffered similar lack of clarity around when to bump major version number as opposed to minor version. To address this we recently adopted the rule[1] that major version number changes have no relation to features. The major number is simply incremented at the start of each calendar year. > But anyway, the more important thing that keeps me concerned is: Someone > once told me that we should get rid of old parameters and interfaces > (like HMP commands) primarily only when we're changing to a new major > version number. As you all know, QEMU has a lot of legacy options, which > are likely rather confusing than helpful for the new users nowadays, > e.g. things like the "-net channel" option (which is fortunately even > hardly documented), but maybe also even the whole vlan/hub concept in > the net code, or legacy parameters like "-usbdevice". If we switch to > version 3.0, could we agree to remove at least some of them? This would, by inference, say that increments of major part of the version number indicate backwards incompatible changes in QEMU API. That is certainly one option for a rule around major version number changes but is not one QEMU seems to have traditionally followed. The release notes show plenty of incompatible changes in arbitrary .x releases. >From the POV of libvirt, I don't think saying that .0 releases have incompatible changes is particularly useful in itself. What *is* useful is to have a clear rule around a deprecation cycle. ie, a rule that says a feature will be marked deprecated for 3 releases or 12 months, before it is permitted to be removed/changed. If that were followed, there is no need to batch up such changes in a .0 release IMHO. Regards, Daniel [1] http://libvirt.org/downloads.html#numbering -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
