[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: Mon, 13 Nov 2017 11:25:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 13.11.2017 10:53, Peter Maydell wrote:
> On 13 November 2017 at 07:14, 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?
> I don't see the point in declaring a 3.0 unless we have some
> sweeping change that merits it. I don't think we should do a
> sweeping change unless we have a well laid out and agreed on
> plan for how the transition works.

Since we declared a lot of interfaces / features as deprecated in QEMU
2.10, we could finally remove them in the release after 2.11. Looking at
that's quite a bit already. That's IMHO a good justification for a 3.0
 > So I would want to see the
> plan discussed and agreed first, and then we can say "ok, and
> we think we can do this in this timescale and so the version
> at $DATE will be 3.0".

We could maybe also start a wiki page to collect ideas for what we want
to do with "3.0" ... but I guess a lot of the possible changes will just
be turned down again since somebody will cry "we need to stay compatible
with older versions! Forever!". So I somehow doubt that this is worth
the effort.

> Changing the version number should be
> the last part of this process, not the first, in my view.

Yeah, but you know how this works in QEMU-Land: Once the 2.12 is
established in the heads of various people, we'll have a hard time to
bump the version number again, since there's always somebody complaining...

So I guess we'll likely end up doing it rather the Linux kernel way one
day - when we feel that the minor number got too big (three digits,
maybe?), we'll switch the major number without any further justification ;-)


reply via email to

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