Re: [PATCH 11/11] Deprecate stable non-JSON -device and -object

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Sep 27, 2021 at 12:17:03PM +0200, Kevin Wolf wrote:
> Am 27.09.2021 um 10:21 hat Daniel P. Berrangé geschrieben:
> > On Mon, Sep 27, 2021 at 10:15:43AM +0200, Paolo Bonzini wrote:
> > > On 24/09/21 11:04, Kevin Wolf wrote:
> > > > We want to switch both from QemuOpts to the keyval parser in the future,
> > > > which results in some incompatibilities, mainly around list handling.
> > > > Mark the non-JSON version of both as unstable syntax so that management
> > > > tools switch to JSON and we can later make the change without breaking
> > > > things.
> > > 
> > > Maybe we need a different section for unstable syntaxes, rather than
> > > overloading deprecated.rst?
> > 
> > This case feels like it hits two scenarios - we want to declare it
> > unstable, which is something we should document in qemu-options.hx.
> 
> Actually, I think a section for unstable syntaxes or generally
> compatibility promises wouldn't hurt. When I checked, I couldn't find
> any documentation about the support status of HMP either.
> 
> Basically, I imagine HMP and non-JSON -device/-object would be on the
> same level: We don't change things without a reason, but if we do want
> to change things, compatibility isn't an argument against making the
> change.
> 
> > We want to also to warn of specific breakage when the impl changes
> > which is something suitable for deprecations.
> 
> We don't do this for HMP either for individual changes.

Well HMP as a whole is considered non-stable, so we don't need to call
out individual things. We've got a simple story that QMP == stable,
HMP == unstable.

The comparison here would be if we declared the entire QEMU CLI to be
unstable, except for JSON syntax args.

> Basically this deprecation notice was meant to make people aware that
> we're lowering the support status from a long-term stable interface to
> HMP-like.

Bearing in mind our previous discussions it feels like our goal is that
we're tending towards a world where we are only wanting to consider
JSON based configuration to be stable, and everything else non-stable.

I think that's a good long term plan, but if we're really doing that
then I think we need to big picture explain it in our docs rather
than mention it in passing against individual args.

BTW I'm also not a fan of deprecating stuff when our documentation is
still using the deprecated syntax and nothing shows the new preferred
syntax. We've got alot of results for  $ git grep -- ' -object'  



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|