[PATCH 1/9] qapi: New special feature flag "unstable"
Daniel P. Berrangé
berrange at redhat.com
Tue Oct 26 09:28:25 UTC 2021
On Tue, Oct 26, 2021 at 10:22:15AM +0100, Dr. David Alan Gilbert wrote:
> * Kevin Wolf (kwolf at redhat.com) wrote:
> > Am 25.10.2021 um 07:25 hat Markus Armbruster geschrieben:
> > > By convention, names starting with "x-" are experimental. The parts
> > > of external interfaces so named may be withdrawn or changed
> > > incompatibly in future releases.
> > >
> > > Drawback: promoting something from experimental to stable involves a
> > > name change. Client code needs to be updated.
> > >
> > > Moreover, the convention is not universally observed:
> > >
> > > * QOM type "input-barrier" has properties "x-origin", "y-origin".
> > > Looks accidental, but it's ABI since 4.2.
> > >
> > > * QOM types "memory-backend-file", "memory-backend-memfd",
> > > "memory-backend-ram", and "memory-backend-epc" have a property
> > > "x-use-canonical-path-for-ramblock-id" that is documented to be
> > > stable despite its name.
> > >
> > > We could document these exceptions, but documentation helps only
> > > humans. We want to recognize "unstable" in code, like "deprecated".
> > >
> > > Replace the convention by a new special feature flag "unstable". It
> > > will be recognized by the QAPI generator, like the existing feature
> > > flag "deprecated", and unlike regular feature flags.
> > >
> > > This commit updates documentation and prepares tests. The next commit
> > > updates the QAPI schema. The remaining patches update the QAPI
> > > generator and wire up -compat policy checking.
> > >
> > > Signed-off-by: Markus Armbruster <armbru at redhat.com>
> >
> > Obviously, replacing the old convention gets rid of the old drawbacks,
> > but adds a new one: While using x- makes it very obvious for a human
> > user that this is an unstable feature, a feature flag in the schema will
> > almost certainly go unnoticed in manual use.
>
> Agreed, I'd keep the x- as well.
>
> Having said that, the x- represents a few different things (that we
> don't currently distinguish):
> - experimental
> - for internal use
> - for debugging/human use
All of those usage scenarios have the same implication though:
Command/data format is liable to change in incompatible ways,
or be deleted, with no prior warning.
I don't think we need to distinguish the use cases - some commands
may belong to two or three of those use cases. All that matters is
that they're considered "unstable" from an API compat POV.
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 :|
More information about the libvir-list
mailing list