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