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

[Daniel P. Berrange]

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

If someone is consuming QEMU via a distro that releases every 6 months
(eg Fedora/Ubuntu), then by the time they see the deprcation message
there may not be much time left before feature deletion. On the flipside
they will not be suspectible to the feature deletion, until the next
major release of their distro, another 6 months after that. This does,
however, not provide much time for them to object to feature removal
to try to convince us to un-deprecate the feature.

If someone is consuming QEMU directly from upstream, it is hard to
answer, because they might rebase to newer QEMU frequently, or they
may stick on a release forever. People in the latter group though
would have a very long time before being impacted by any delation,
while people in the former group would see the deprecation reasonably
early.

If we publicise the deprecations in release notes, that gives a more
visible heads up to people than we've ever had in the past. So even
if they're not consuming new QEMU releases any time soon, they still
stand a chance of hearing about the planned feature removal and
planning ahead.

>From libvirt POV, we track QEMU activity quite closely and release
libvirt once a month, so that leaves libvirt developers 8 releases
in which to get a fix done to stop using the deprecated feature,
so I think that's acceptable for libvirt.


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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|