On Fri, Nov 27, 2020 at 14:45:12 +0300, Roman Bolshakov wrote: > On Fri, Nov 27, 2020 at 12:21:54PM +0100, Peter Krempa wrote: > > On Fri, Nov 27, 2020 at 10:50:59 +0000, Daniel Berrange wrote: > > > Copying libvir-list for the deprecation warning. > > > > > > > > > On Mon, Nov 16, 2020 at 04:10:11PM +0300, Roman Bolshakov wrote: > > > > 'query-accel' QMP command should be used instead. > > > > > > > > Signed-off-by: Roman Bolshakov <r.bolshakov@xxxxxxxxx> > > > > --- [...] > > We try hard to stay on top of such changes by using the new interface as > > soon as possible, but that is very hard if the replacement changes > > during the dev cycle. > > > > I see, thanks for the explanation! Perhaps I'll drop deprecation from > the series to avoid the issue. > > Then as soon as libvirt gets support for queyring accels we might > consider deprecation again. I don't want to imply that it's entirely necessary to postpone it, but in such cases the new API which was added to replace the old one needs to be considered a bit more strongly until the release. The main reason for this is that libvirt has tests whether it uses any deprecated interface. If anything is marked as deprecated and our tests flag it, we add an override. Usually the override is added in the same patchset which actually implements the new approach. We obviously can add an override and then wait for the supported interface, but once the override is added there's nothing to remind us later on, so I generally like to have everything in one series. As you can see this has an issue when we have to add support for a unreleased interface, which may change during the dev cycle or plainly forget that something got deprecated as we've already added an override. This mainly comes from libvirt trying to keep on top of the changes so we refresh the QMP schema during qemu's dev cycle multiple times. Obviously the argument that we try to depend on unreleased functionality can be used, but that would be to detrement of progress IMO.
