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 <coh...@redhat.com> wrote: > >>>> On Mon, 13 Nov 2017 08:14:28 +0100 > >>>> Thomas Huth <th...@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 :|
