[PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[Philippe Mathieu-Daudé]

SchemaInfoEnumMember::values field has been deprecated for
more than 5 years (see commit 75ecee72625 "qapi: Enable enum
member introspection to show more than name"), it should be
safe enough to remove.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 docs/about/deprecated.rst       |  6 ------
 docs/about/removed-features.rst |  7 +++++++
 qapi/introspect.json            | 12 +-----------
 scripts/qapi/introspect.py      |  3 +--
 4 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index a6d6a713265..afb0d383c27 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -101,12 +101,6 @@ Use the more generic commands ``block-export-add`` and ``block-export-del``
 instead.  As part of this deprecation, where ``nbd-server-add`` used a
 single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.
 
-``query-qmp-schema`` return value member ``values`` (since 6.2)
-'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-Member ``values`` in return value elements with meta-type ``enum`` is
-deprecated.  Use ``members`` instead.
-
 ``drive-backup`` (since 6.2)
 ''''''''''''''''''''''''''''
 
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index e75db084108..9eb4ef67ff4 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -787,6 +787,13 @@ $VM,debug-threads=on`` instead.
 
 This argument has always been ignored.
 
+``query-qmp-schema`` return value member ``values`` (removed in 11.0)
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+Member ``values`` in return value elements with meta-type ``enum`` has
+been replaced by ``members`` instead.
+
+
 QEMU Machine Protocol (QMP) events
 ----------------------------------
 
diff --git a/qapi/introspect.json b/qapi/introspect.json
index c8432c8ed8e..71b10baabaf 100644
--- a/qapi/introspect.json
+++ b/qapi/introspect.json
@@ -159,22 +159,12 @@
 # @members: the enum type's members, in no particular order.
 #     (since 6.2)
 #
-# @values: the enumeration type's member names, in no particular
-#     order.  Redundant with @members.  Just for backward
-#     compatibility.
-#
-# Features:
-#
-# @deprecated: Member @values is deprecated.  Use @members instead.
-#
 # Values of this type are JSON string on the wire.
 #
 # Since: 2.5
 ##
 { 'struct': 'SchemaInfoEnum',
-  'data': { 'members': [ 'SchemaInfoEnumMember' ],
-            'values': { 'type': [ 'str' ],
-                        'features': [ 'deprecated' ] } } }
+  'data': { 'members': [ 'SchemaInfoEnumMember' ] } }
 
 ##
 # @SchemaInfoEnumMember:
diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py
index 7e28de2279a..daeb3d77b23 100644
--- a/scripts/qapi/introspect.py
+++ b/scripts/qapi/introspect.py
@@ -318,8 +318,7 @@ def visit_enum_type(self, name: str, info: Optional[QAPISourceInfo],
                         prefix: Optional[str]) -> None:
         self._gen_tree(
             name, 'enum',
-            {'members': [self._gen_enum_member(m) for m in members],
-             'values': [Annotated(m.name, m.ifcond) for m in members]},
+            {'members': [self._gen_enum_member(m) for m in members]},
             ifcond, features
         )
 
-- 
2.53.0

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[Pierrick Bouvier]

On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote:
> SchemaInfoEnumMember::values field has been deprecated for
> more than 5 years (see commit 75ecee72625 "qapi: Enable enum
> member introspection to show more than name"), it should be
> safe enough to remove.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   docs/about/deprecated.rst       |  6 ------
>   docs/about/removed-features.rst |  7 +++++++
>   qapi/introspect.json            | 12 +-----------
>   scripts/qapi/introspect.py      |  3 +--
>   4 files changed, 9 insertions(+), 19 deletions(-)
> 

By curiosity, is this patch goal is simply to remove a deprecated 
feature/code, or does it unlock something beyond it?
No judgment here, that's a genuine question, and both are valid reasons!

Looks good to me, to the limit of my qapi knowledge :).
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

Regards,
Pierrick

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[Philippe Mathieu-Daudé]

On 24/3/26 04:19, Pierrick Bouvier wrote:
> On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote:
>> SchemaInfoEnumMember::values field has been deprecated for
>> more than 5 years (see commit 75ecee72625 "qapi: Enable enum
>> member introspection to show more than name"), it should be
>> safe enough to remove.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> ---
>>   docs/about/deprecated.rst       |  6 ------
>>   docs/about/removed-features.rst |  7 +++++++
>>   qapi/introspect.json            | 12 +-----------
>>   scripts/qapi/introspect.py      |  3 +--
>>   4 files changed, 9 insertions(+), 19 deletions(-)
>>
> 
> By curiosity, is this patch goal is simply to remove a deprecated 
> feature/code, or does it unlock something beyond it?
> No judgment here, that's a genuine question, and both are valid reasons!

In a previous thread Daniel said past deprecation period, feature
must be removed, otherwise undeprecated and re-introduced. I'm just
trying to be consistent with the deprecation process, removing what
doesn't seem worth to re-introduce (for the code I'm able to figure
out at least).

Maybe we should clarify the deprecation process, clarifying that,
and mentioning that maintainers sending pull request to commit
patches with deprecations are also a commitment to remove code
when the proper released is out.

> Looks good to me, to the limit of my qapi knowledge :).
> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

Thanks!

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[Peter Krempa]

On Mon, Mar 23, 2026 at 20:19:45 -0700, Pierrick Bouvier wrote:
> On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote:
> > SchemaInfoEnumMember::values field has been deprecated for
> > more than 5 years (see commit 75ecee72625 "qapi: Enable enum
> > member introspection to show more than name"), it should be
> > safe enough to remove.
> > 
> > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > ---
> >   docs/about/deprecated.rst       |  6 ------
> >   docs/about/removed-features.rst |  7 +++++++
> >   qapi/introspect.json            | 12 +-----------
> >   scripts/qapi/introspect.py      |  3 +--
> >   4 files changed, 9 insertions(+), 19 deletions(-)
> > 
> 
> By curiosity, is this patch goal is simply to remove a deprecated
> feature/code, or does it unlock something beyond it?
> No judgment here, that's a genuine question, and both are valid reasons!

This patch also shaves off a nice 1.3k lines of duplicate data from the
prettified reply from query-qmp-schema.

(In libvirt we capture dumps of the schema which we use for internal
testing as well as validation that the monitor command handlers and
commandline generators (by proxy) don't use deprecated and or
non-existent members.)

> Looks good to me, to the limit of my qapi knowledge :).
> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

On behalf of libvirt (and since I didn't look at the code at all; just
at the output):

ACKed-by: Peter Krempa <pkrempa@redhat.com>

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[Markus Armbruster]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 24/3/26 04:19, Pierrick Bouvier wrote:
>> On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote:
>>> SchemaInfoEnumMember::values field has been deprecated for
>>> more than 5 years (see commit 75ecee72625 "qapi: Enable enum
>>> member introspection to show more than name"), it should be
>>> safe enough to remove.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>> ---
>>>   docs/about/deprecated.rst       |  6 ------
>>>   docs/about/removed-features.rst |  7 +++++++
>>>   qapi/introspect.json            | 12 +-----------
>>>   scripts/qapi/introspect.py      |  3 +--
>>>   4 files changed, 9 insertions(+), 19 deletions(-)
>>>
>> By curiosity, is this patch goal is simply to remove a deprecated feature/code, or does it unlock something beyond it?
>> No judgment here, that's a genuine question, and both are valid reasons!
>
> In a previous thread Daniel said past deprecation period, feature
> must be removed, otherwise undeprecated and re-introduced.

I think that's too rigid.

Why do we deprecate features?  Reasons include:

* A feature may have become too much of a burden to support.  We
  deprecate it with the firm intent to remove it at the earliest
  opportunity.  The motivation is to help developers, and deprecation is
  the means to do so without inflicting unnecessary pain on users.

* A certain interface has turned out to be too limited, necessitating a
  more expressive one.  Now we have two ways to do the same thing.  We
  deprecate the limited one to guide users to the new one, because
  that's the one we think they should use for their own good.  The
  motivation is to help users, and deprecation is the means.  Removing
  the old interface later on helps future users a bit more.  It also
  inconveniences any remaining users of the old interface.

Mixed reasons are possible.  For instance, we might start for the second
reason (need a new interface), then find the first reason now applies
(maintaining the old interface in addition is bothersome).

Removing a deprecated feature is always a tradeoff, and time is commonly
a factor.  The deprecation grace period is merely a lower bound we
commit to so we don't surprise users.  docs/about/deprecated.rst:

    The [deprecated] feature will remain functional for the release in
    which it was deprecated and one further release. After these two
    releases, the feature is liable to be removed.

Note "liable".

>                                                            I'm just
> trying to be consistent with the deprecation process, removing what
> doesn't seem worth to re-introduce (for the code I'm able to figure
> out at least).
>
> Maybe we should clarify the deprecation process, clarifying that,
> and mentioning that maintainers sending pull request to commit
> patches with deprecations are also a commitment to remove code
> when the proper released is out.

I believe that wouldn't be a clarification of actual practice, it would
be a change of practice.  We can certainly debate such a change.

Back to the patch.  SchemaInfoEnumMember member @values has been
deprecated for five years.  I figure by now the benefit of simplifying
the interface outweighs the inconvenience of removing the deprecated
part.

I'd like an Acked-by from libvirt developers, though.

[...]

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[Markus Armbruster]

Peter Krempa <pkrempa@redhat.com> writes:

> On Mon, Mar 23, 2026 at 20:19:45 -0700, Pierrick Bouvier wrote:
>> On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote:
>> > SchemaInfoEnumMember::values field has been deprecated for
>> > more than 5 years (see commit 75ecee72625 "qapi: Enable enum
>> > member introspection to show more than name"), it should be
>> > safe enough to remove.
>> > 
>> > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> > ---
>> >   docs/about/deprecated.rst       |  6 ------
>> >   docs/about/removed-features.rst |  7 +++++++
>> >   qapi/introspect.json            | 12 +-----------
>> >   scripts/qapi/introspect.py      |  3 +--
>> >   4 files changed, 9 insertions(+), 19 deletions(-)
>> > 
>> 
>> By curiosity, is this patch goal is simply to remove a deprecated
>> feature/code, or does it unlock something beyond it?
>> No judgment here, that's a genuine question, and both are valid reasons!
>
> This patch also shaves off a nice 1.3k lines of duplicate data from the
> prettified reply from query-qmp-schema.
>
> (In libvirt we capture dumps of the schema which we use for internal
> testing as well as validation that the monitor command handlers and
> commandline generators (by proxy) don't use deprecated and or
> non-existent members.)
>
>> Looks good to me, to the limit of my qapi knowledge :).
>> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>
> On behalf of libvirt (and since I didn't look at the code at all; just
> at the output):
>
> ACKed-by: Peter Krempa <pkrempa@redhat.com>

Thank you, Peter!

Reviewed-by: Markus Armbruster <armbru@redhat.com>

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field

[Daniel P. Berrangé]

On Tue, Mar 24, 2026 at 08:02:48AM +0100, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> 
> > On 24/3/26 04:19, Pierrick Bouvier wrote:
> >> On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote:
> >>> SchemaInfoEnumMember::values field has been deprecated for
> >>> more than 5 years (see commit 75ecee72625 "qapi: Enable enum
> >>> member introspection to show more than name"), it should be
> >>> safe enough to remove.
> >>>
> >>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> >>> ---
> >>>   docs/about/deprecated.rst       |  6 ------
> >>>   docs/about/removed-features.rst |  7 +++++++
> >>>   qapi/introspect.json            | 12 +-----------
> >>>   scripts/qapi/introspect.py      |  3 +--
> >>>   4 files changed, 9 insertions(+), 19 deletions(-)
> >>>
> >> By curiosity, is this patch goal is simply to remove a deprecated feature/code, or does it unlock something beyond it?
> >> No judgment here, that's a genuine question, and both are valid reasons!
> >
> > In a previous thread Daniel said past deprecation period, feature
> > must be removed, otherwise undeprecated and re-introduced.
> 
> I think that's too rigid.

Definitely s/must/should/.

> 
> Why do we deprecate features?  Reasons include:
> 
> * A feature may have become too much of a burden to support.  We
>   deprecate it with the firm intent to remove it at the earliest
>   opportunity.  The motivation is to help developers, and deprecation is
>   the means to do so without inflicting unnecessary pain on users.
> 
> * A certain interface has turned out to be too limited, necessitating a
>   more expressive one.  Now we have two ways to do the same thing.  We
>   deprecate the limited one to guide users to the new one, because
>   that's the one we think they should use for their own good.  The
>   motivation is to help users, and deprecation is the means.  Removing
>   the old interface later on helps future users a bit more.  It also
>   inconveniences any remaining users of the old interface.
> 
> Mixed reasons are possible.  For instance, we might start for the second
> reason (need a new interface), then find the first reason now applies
> (maintaining the old interface in addition is bothersome).
> 
> Removing a deprecated feature is always a tradeoff, and time is commonly
> a factor.  The deprecation grace period is merely a lower bound we
> commit to so we don't surprise users.  docs/about/deprecated.rst:
> 
>     The [deprecated] feature will remain functional for the release in
>     which it was deprecated and one further release. After these two
>     releases, the feature is liable to be removed.
> 
> Note "liable".
> 
> >                                                            I'm just
> > trying to be consistent with the deprecation process, removing what
> > doesn't seem worth to re-introduce (for the code I'm able to figure
> > out at least).
> >
> > Maybe we should clarify the deprecation process, clarifying that,
> > and mentioning that maintainers sending pull request to commit
> > patches with deprecations are also a commitment to remove code
> > when the proper released is out.
> 
> I believe that wouldn't be a clarification of actual practice, it would
> be a change of practice.  We can certainly debate such a change.

Yes, that's too rigid. Some of the things are very complicated to remove
from the code and so it is valid for maintainers to want to focus on
other things as a higher priority. It is upto maintainers to decide
what priorities deliver most value.  I've tried several times to remove
some of the very old deprecated block features, and it is very hard to
untangle the deps and get tests fixed.

The deprecation process is there to put users on notice, and give
maintainers a clear date, after which they have the freedom to
choose to break / remove things.

The ideal situation is that things are removed promptly after the
2 release cycle marker, but sometimes reality intervenes, sometimes
for a very long time.

I think it is unhelpful to let things fester in a deprecated state
for many years though, as it potentially leads to a situation where
users cease to believe they'll ever be removed, undermining the goal
of deprecation.


Perhaps we could open tickets for each deprecated item. That would
give us a place to record some of the info about the removal process
that contributors need to remember, and any related discussion around
the process. ?

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|