qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a


From: Markus Armbruster
Subject: Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)
Date: Thu, 09 Mar 2017 13:33:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

"Daniel P. Berrange" <address@hidden> writes:

> On Wed, Mar 08, 2017 at 12:22:24PM +0100, Thomas Huth wrote:
>> On 08.03.2017 11:03, Peter Maydell wrote:
>> > On 8 March 2017 at 09:26, Thomas Huth <address@hidden> wrote:
>> >> But anyway, the more important thing that keeps me concerned is: Someone
>> >>  once told me that we should get rid of old parameters and interfaces
>> >> (like HMP commands) primarily only when we're changing to a new major
>> >> version number. As you all know, QEMU has a lot of legacy options, which
>> >> are likely rather confusing than helpful for the new users nowadays,
>> >> e.g. things like the "-net channel" option (which is fortunately even
>> >> hardly documented), but maybe also even the whole vlan/hub concept in
>> >> the net code, or legacy parameters like "-usbdevice". If we switch to
>> >> version 3.0, could we agree to remove at least some of them?
>> > 
>> > I think if we are going to deprecate and remove options we need
>> > a clear transition plan for doing so, which means at least one
>> > release where options are "still works, but warn that they
>> > are going away with pointer to documentation or similar info
>> > about their replacement syntax", before actually dropping them.
>> 
>> Yes, that's certainly a good idea. But as Daniel suggested in his mail,
>> I think we should also have the rule that the option should be marked as
>> deprecated in multiple releases first - so that the users have a chance
>> to speak up before something gets really removed (otherwise the option
>> could be removed right on the first day after the initial release with
>> the deprecation message, so there is no time for the user to notice this
>> and complain). Not sure whether we need three releases, as Daniel
>> suggested, though, but if that's common sense, that's fine for me, too.
>
> FYI, I didn't put any thought into my 3 releases / 12 months numbers. I
> just arbitrarily picked them out of the hat, so don't consider it my
> endorsement of that particular length of time :-) I think 2 is the minimum
> number of releases we should deprecate for, beyond that, I'm open minded

I don't think a hard rule for the grace period makes sense.  It really
depends.  A guideline like "normally 12 months" is of course fine.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]