Peter Krempa <pkrempa@xxxxxxxxxx> writes: > On Fri, Nov 27, 2020 at 16:44:05 +0100, Markus Armbruster wrote: >> Peter Krempa <pkrempa@xxxxxxxxxx> writes: >> >> > 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: > > [...] > >> > 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. >> >> I understand your concerns. >> >> We have a somewhat similar problem in QEMU: there's nothing to remind us >> later on that the old interface still needs to be deprecated. > > Oh, yes. That's basically the same thing. > > The thing is that changes to the new interface are very rare, but very > real. Since I don't really want to increase the burden for any normal > scenario. > > I'd also very much like to keep libvirt pulling in snapshots of qemu's > capabilities/qapi schema etc throughout the development cycle. It allows > us to adapt faster and develop features simultaneously. > > This unfortunately undermines my own arguments partially as libvirt > regularly develops features on top of unreleased qemu features so we are > regularly risking very similar circumstances. The small but important > difference though is, that releasing a broken feature is not as bad as > breaking an existing feature. > > As a conclusion of the above I'd basically prefer a sort of gentleman's > agreement, that new APIs become 'somewhat' stable at the moment the > commit deprecating the old interface hits upstream. > > The 'somewhat'-stable API would mean that any changes to the new API > should be consulted with libvirt so that we can either give a go-ahead > that we didn't adapt yet, disable the adaptation until the changes can > be done, or another compromise depending on what's the state. > > I know it's hard to enforce, but probably the cheapest in terms of > drawbacks any other solution would be. We can and should try. Can we flag problematic interface changes automatically? Semantic changes, no. What about changes visible in query-qmp-schema? > I'll probably keep notifying patchsets which implement and deprecate old > api at the same time to keep in mind that we need to be kept in touch, > but I really don't want to impose any kind of extra process to > development on either side. Thanks!
