Peter Maydell <peter.maydell@xxxxxxxxxx> writes: > On 6 July 2018 at 15:56, Kevin Wolf <kwolf@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
