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.
