Re: [Qemu-devel] QEMU 3.0 ?

[Thomas Huth]

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