[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU 3.0 ?

From: Thomas Huth
Subject: Re: [Qemu-devel] QEMU 3.0 ?
Date: Thu, 23 Nov 2017 12:40:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]