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: Daniel P. Berrange
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: Wed, 8 Mar 2017 11:24:41 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|



reply via email to

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