Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru> writes: > On 18.10.23 15:02, Markus Armbruster wrote: >> Daniel P. Berrangé <berra...@redhat.com> writes: >> >>> On Wed, Oct 18, 2023 at 06:51:41AM -0400, Michael S. Tsirkin wrote: >>>> On Wed, Oct 18, 2023 at 12:36:10PM +0200, Markus Armbruster wrote: >>>>>> x- seems safer for management tool that doesn't know about "unstable" >>>>>> properties.. >>>>> >>>>> Easy, traditional, and unreliable :) >>>> >>>>>> But on the other hand, changing from x- to no-prefix is already >>>>>> done when the feature is stable, and thouse who use it already >>>>>> use the latest version of interface, so, removing the prefix is >>>>>> just extra work. >>>>> >>>>> Exactly. >>>>> >>>> >>>> I think "x-" is still better for command line use of properties - we >>>> don't have an API to mark things unstable there, do we? >>> >>> Personally I like to see "x-" prefix present *everywhere* there is >>> an unstable feature, and consider the need to rename when declaring >>> it stable to be good thing as it sets an easily identifiable line >>> in the sand and is self-evident to outside observers. >>> >>> The self-documenting nature of the "x-" prefer is what makes it most >>> compelling to me. A patch submission, or command line invokation or >>> an example QMP command, or a bug report, that exhibit an 'x-' prefix >>> are an immediate red flag to anyone who sees them. >> Except when it isn't, like in "x-origin". >> > > Interesting how many such stable x-FOO things we have?
I don't know. I think the more interesting question is how many *unstable* things we have that aren't named x-FOO. I'm thinking of stuff that was never intended to be exposed externally. QOM/qdev properties, mostly. For extra spiciness, throw in qom-get and especially qom-set. > Probably we could deprecate and than rename them? I guess we can if we care :)