Re: [PATCH 4/4] qapi: introduce CONFIG_READ event

[Markus Armbruster]

Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:

> On 18.10.23 15:02, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@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 :)