Re: [libvirt PATCH 0/5] Formalize the deprecation of arguments in virsh
On Tue, Mar 23, 2021 at 14:50:09 +0100, Michal Privoznik wrote:
On 3/23/21 2:42 PM, Daniel P. Berrangé wrote:
> On Tue, Mar 23, 2021 at 02:36:19PM +0100, Michal Privoznik wrote:
> > On 3/22/21 5:09 PM, Tim Wiederhake wrote:
> > > virsh has several arguments that are better not used. This series
introduces
> > > a formal way of marking them as deprecated.
> >
> > Commit messages are rather sparse. What we currently have is hiding options
> > we deem obsolete from users and replacing them with better ones (just :Ggrep
> > VSH_OT_ALIAS). No error message, no warning. What makes these you picked
> > special? I'm not against reporting that an option is obsolete, but I
don't
> > quite understand why we need a different way for obsoleting those three.
>
> Also the general idea of deprecation is that the thing will be deleted
> eventually, which is not something we intended to do with these options.
> Basically there's a better way to do these things, but we're not going
> to break existing usage, so if users are happy with what they're doing
> they don't need to change.
>
To be fair we never promised virsh to be stable, did we? We are trying to
I'd say we do, at least for the reasonably machine-usable interfaces
(for output [1]), thus any input options should be treated as such.
keep it as backwards compatible as we can (and so far I guess we
didn't have
a single instance of bad example), but I wouldn't mind telling users (esp.
in interactive mode) that --optionX is now called --optionY.
Well, that's what we do with the alias and documentation changes. But
removing --optionX completely would be wrong:
- It needlessly breaks scripts
- If you decide to print a deprecation warning, the code usually won't
be much simpler.
- most cases are covered by use of _ALIAS to a better name
The only thing that IMO should be removed but I didn't for compatibility
is the 'secret-set-value's 'base64' parameter as that is insecure. There
isn't a compatible replacement though.
[1] Table outputs and other clearly human-targetted output may obviously
break, but for many of the output cases we provide machine-friendly
variants, such as '--uuid'/'--name' for listing APIs.