qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU 3.0 ?


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] QEMU 3.0 ?
Date: Thu, 23 Nov 2017 11:11:05 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Thu, Nov 23, 2017 at 11:57:34AM +0100, Thomas Huth wrote:
> On 23.11.2017 11:17, Peter Maydell wrote:
> > On 23 November 2017 at 10:03, Cornelia Huck <address@hidden> wrote:
> >> On Mon, 13 Nov 2017 08:14:28 +0100
> >> Thomas Huth <address@hidden> wrote:
> >>
> >>> By the way, before everybody now introduces "2.12" machine types ... is
> >>> there already a consensus that the next version will be "2.12" ?
> >>>
> >>> A couple of months ago, we discussed that we could maybe do a 3.0 after
> >>> 2.11, e.g. here:
> >>>
> >>>  https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg05056.html
> >>>
> >>> I'd still like to see that happen... Peter, any thoughts on this?
> >>
> >> So, as I just thought about preparing the new machine for s390x as
> >> well: Did we reach any consensus about what the next qemu version will
> >> be called?
> > 
> > I haven't seen any sufficiently solid plan to make me want to
> > pick anything except "2.12".
> 
> I still don't think that we need a big plan for this... The change from
> 1.7 to 2.0 was also rather arbitrary, wasn't it?
>
> Anyway, I've now started a Wiki page to collect ideas:
> 
>  https://wiki.qemu.org/Features/Version3.0
> 
> Maybe we can jump to version 3.0 if there are enough doable items on the
> list that we can all agree upon.

>From the mgmt app / libvirt POV, I'm against the idea of doing such an
API incompatible release associated with major versions. The whole point
of the documented deprecation timeframe, was that we can incrementally
remove legacy interfaces without having a big bang break the whole
world. It gives management apps a clear warning on what will go away,
and a consistent timeframe for how long they have to adapt before it
goes away.

Tieing breakage to "major" releases, gives a very inconsistent lead up
for mgmt apps - some features will live on the "to be removed" list
for years, while other features put on the 3.0 kill list may only have
less than a single release warning before being removed. What's worse
is that, for features which change their impl rather than being deleted,
apps have to adapt to everything at the same time. It

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]