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. Thomas
