[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
https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
that's quite a bit already. That's IMHO a good justification for a 3.0
already.
> 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 ;-)
Thomas
- [Qemu-devel] [PATCH for-2.12 v3 00/11] spapr: introduce an IRQ allocator at the machine level, Cédric Le Goater, 2017/11/10
- Re: [Qemu-devel] QEMU 3.0 ? (was: [PATCH for-2.12 v3 01/11] spapr: add pseries 2.12 machine type), Cornelia Huck, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ? (was: [PATCH for-2.12 v3 01/11] spapr: add pseries 2.12 machine type), Peter Maydell, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Thomas Huth, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Daniel P. Berrange, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Thomas Huth, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Daniel P. Berrange, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Thomas Huth, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Thomas Huth, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23