Re: [libvirt] [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters
John Snow writes:
[...]
This might be OK to do right away, though.
I asked Markus this not too long ago; do we want to amend the QAPI
schema specification to allow commands to return with "Warning" strings,
or "Deprecated" stings to allow in-band deprecation notices for cases
like these?
example:
{ "return": {},
"deprecated": True,
"warning": "Omitting filter-node-name parameter is deprecated, it will
be required in the future"
}
There's no "error" key, so this should be recognized as success by
compatible clients, but they'll definitely see the extra information.
Part of my motivation is to facilitate a more aggressive deprecation of
legacy features by ensuring that we are able to rigorously notify users
through any means that they need to adjust their scripts.
I like this approach even if there is no consumer today. It does not
hurt, and it is indeed a motivation to develop consumers that care.
I personally find this much easier to swallow than any kind of crash on
deprecation, which already at the BoF seemed like a really big hammer to
kill a fly.
CC'ing Andrea as well, because we discussed recently about how to deal
with error checking in general, and if a new error checking framework is
being put in place, adding deprecation to the thinking could be a good
idea.
--
Cheers,
Christophe de Dinechin (IRC c3d)