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

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On 6 July 2018 at 15:56, Kevin Wolf <address@hidden> wrote:
>> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben:
>>> That way, we can still easily remove old cruft (case (a)), but still
>>> accommodate cases like this (case (c)). The obvious drawback is that
>>> we'd need someone to curate the deprecation watchlist, to poke the
>>> users we're waiting for, and probably remove anyway after some time if
>>> they don't get their act together.
>>
>> The problem is that things are only starting to move after two releases
>> have passed.
>
> Right, so clearly just "put a note in the documentation" isn't
> sufficient advertisement/prodding of things going away.

Yes.  Ideas on more forceful notification have been tossed around, we
just have to act on them.

>                                                         (Also, two
> releases is pretty fast. Many of our users will be using distro
> packaged versions of QEMU which will lag further behind than
> bleeding-edge users. The system version of QEMU on my desktop
> machine is 2.5...)

If you consume QEMU in a way that's impacted by the changes the
deprecation policy guards, you have two sane options:

* Track upstream deprecation, either continuously, or at least right
  after a QEMU release.  Since 2.10, they're collected in qemu-doc
  appendix "Deprecated features".

* Batch that work before you switch QEMU versions.  Make sure to
  allocate enough time.

If you consume only downstream versions of QEMU, and don't want to track
upstream, go ahead and pick the second option.  It should do even if you
leap from 2.5 (December 2015) all the way to 3.0.