Re: [Qemu-devel] [PATCH v3 0/2] Document deprecated features & support lifecycle

[Thomas Huth]

On 04.07.2017 14:16, Daniel P. Berrange wrote:
> On Tue, Jul 04, 2017 at 01:00:54PM +0100, Peter Maydell wrote:
>> On 4 July 2017 at 12:14, Daniel P. Berrange <address@hidden> wrote:
>>> This is a followup to
>>>
>>>   v1: https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg02390.html
>>>   v2: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg01286.html
>>>
>>> The goal is to clarify to users & app developers what they can expect
>>> from QEMU in terms of feature lifecycle & any deprecation policy should
>>> it be neccessary to remove features.
>>>
>>> The list of features marked as deprecated was determined by looking at
>>> the QEMU source for the word "deprecated'. It was then compared with
>>> the doc Thomas put up at http://wiki.qemu.org/Features/LegacyRemoval
>>>
>>> Key differences with the wiki page that Thomas wrote up vs patch 2
>>> in this series
>>>
>>>  - Deprecated features are given a fixed lifespan of 2 releases,
>>>    rather than listing deletion at a future "major" v3.0.0 release.
>>>    This ensures that applications like libvirt have a predictable
>>>    fixed amount of time to react to deprecations.
>>
>> That's 8 months. Is that enough time for QEMU versions to get into
>> distros and out to users? (I don't necessarily think it's too short,
>> but it seems worth thinking about.)
[...]
> I think 2 releases is the minimum acceptable window of deprecation,
> but I also wouldn't object if we wanted to make it 3 release, so
> there's a nice clear "1 year" grace period before deletion. That
> would make it slightly more likely that users of distros would
> see the warning before the feature has actually been deleted.

Last time we discussed this, nobody insisted on 3 releases, so I think
we should start with 2 releases. If somebody complains later that this
is too short, we can still bump it to 3 releases instead.

 Thomas