[Top][All Lists]

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

Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive

From: Peter Maydell
Subject: Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial
Date: Wed, 4 Jul 2018 17:14:02 +0100

On 4 July 2018 at 14:34, Kevin Wolf <address@hidden> wrote:
> Essentially, what is important to me isn't getting these options dropped
> exactly in 3.0, but not setting a bad precedence that deprecation isn't
> actually worth anything. We may easily end up with this deprecation
> process:
> depreate a feature
> release QEMU version n + 1
> release QEMU version n + 2
> remove the feature
> while libvirt hasn't removed use of the feature:
>     # ...and why should it when everything is still working?
>     reinstate the feature
>     release QEMU version n + x
>     remove the feature

My take on the deprecation policy essentially is that it gives
us a *minimum* bar for how soon we can drop something. We
shouldn't be using it as an "always target this speed for
dropping something" -- we ought to be pragmatic. We can
drop stuff that's unused quickly, but should be slower
for things that still have major users (or reconsider
the deprecation entirely, potentially). There should be
a balance between making our work as developers easier and
inconveniencing our users.

In this particular case, reverting this deletion seems like
a fairly easy call to me.

We should also definitely work on improving how we can
let management-layer developers easily test that they're
not accidentally relying on deprecated features, certainly
(and also on better documentation for command line users
of how to switch away from deprecated features -- for
instance I am still using -redir in some of my scripts
because the warning about it being deprecated is not
precise about what exact command line option can be used
instead, especially for the case where the ethernet device
is builtin rather than created with -device...)

-- PMM

reply via email to

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