Re: [libvirt] [PATCH 2/2] qapi: deprecate implicit filters

14.08.2019 13:07, Vladimir Sementsov-Ogievskiy wrote: > To get rid of implicit filters related workarounds in future let's > deprecate them now. Interesting, could we deprecate implicit filter without deprecation of unnecessity of parameter? As actually, it's good when this parameter is not necessary, in most cases user is not interested in node-name.

Obviously we can do the following: 1. In 4.2 we deprecate unnecessity, which implies deprecation of implicit filters 2. After some releases in 4.x we can drop deprecated functionality, so we drop it together with implicit filters. And, in same release 4.x we return it back (as it's compatible change :) but without implicit filters (so, if filter-node-name not specified, we just create explicit filter with autogenerated node-name) So, effectively we just drop "deprecation mark" together with implicit filters, which is nice but actually confusing. Instead, we may do 1. In 4.2 deprecate 2. In 4.x drop optionality together with implicit filters 3. In 4.y (y > x of course) return optionality back

It's a bit safer, but for users who miss releases [4.x, 4.y) it's no difference.. Or we just write in spec, that implicit filters are deprecated? But we have nothing about implicit filters in spec. More over, we directly write that we have filter, and if parameter is omitted it's node-name is autogenerated. So actually, the fact the filter is hidden when filter-node-name is unspecified is _undocumented_. So, finally, it looks like nothing to deprecated in specification, we can just drop implicit filters :) What do you think?