Re: [libvirt] [Qemu-block] [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.