I also wonder if you should add 'feature' : [ 'unstable' ].
On the upside, it would mark the event as unstable, but I don't know what the
consequences are exactly.
docs/devel/qapi-code-gen.rst:
Special features
~~~~~~~~~~~~~~~~
Feature "deprecated" marks a command, event, enum value, or struct
member as deprecated. It is not supported elsewhere so far.
Interfaces so marked may be withdrawn in future releases in accordance
with QEMU's deprecation policy.
Feature "unstable" marks a command, event, enum value, or struct
member as unstable. It is not supported elsewhere so far. Interfaces
so marked may be withdrawn or changed incompatibly in future releases.
Yeah, I saw that, but wasn't aware of -compat, thanks.
See also -compat parameters unstable-input, unstable-output, both
intended for "testing the future".
Also I guess one can remove qemu events without breaking backwards
compatibility,
since they just won't be emitted? Unless I guess you specify that a event must
occur under certain situations and the client waits on it?
Events are part of the interface just like command returns are. Not
emitting an event in a situation where it was emitted before can easily
break things. Only when the situation is no longer possible, the event
can be removed safely.
@Pierre, seems it would be a good idea to mark all changes to qmp unstable, not
just
set-cpu-topology, can just remove it later after all.