Re: [Qemu-devel] QEMU 3.0 ?

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Nov 23, 2017 at 12:24:24PM +0100, Thomas Huth wrote:
> On 23.11.2017 12:11, Daniel P. Berrange wrote:
> > 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 <cohuck@redhat.com> wrote:
> >>>> On Mon, 13 Nov 2017 08:14:28 +0100
> >>>> Thomas Huth <thuth@redhat.com> 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.
> 
> Yes, I agree ... that's why I tried to split the list into a "doable"
> part (which hopefully does not mean any breakage for the upper stack),
> and a "controversial" part (which we could use for collecting ideas, but
> it is likely not feasible to do it any time soon). Sorry for not stating
> this more clearly.

Your "doable" list includes removing all deprecated features, which
basically just nullifies the deprecation process, which declared
that they would live for 2 releases with a warning and then be
deleted. That will break the upper stack.

For the --accel item though, if that's doable without breakage then
there's no point delaying that until a 3.0 release. Just do it as
soon as its functionally ready for any release.

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