On 23.11.2017 12:33, Daniel P. Berrange wrote: > 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.
Sorry again, that's not what I meant here. I meant to respect the 2 release cycle warning period - and used "accordingly" here to express that. Looks like this was not very clear :-( I've rephrased the sentence now, I hope it is now not ambiguous any more. Thomas
