On Tue, Oct 26, 2021 at 10:22:15AM +0100, Dr. David Alan Gilbert wrote: > * Kevin Wolf (kwolf@xxxxxxxxxx) 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@xxxxxxxxxx> > > > > 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 :|
