On Tue, Jul 04, 2017 at 01:00:54PM +0100, Peter Maydell wrote: > On 4 July 2017 at 12:14, Daniel P. Berrange <berra...@redhat.com> 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 :|
