On Wed, 2 May 2018 09:16:32 +0100 Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Wed, May 02, 2018 at 09:29:39AM +0200, Markus Armbruster wrote: > > How can I provide both the old command line in all its quirky glory and > > a QAPIfied command line? Unless we can, the deprecation policy doesn't > > help one bit, it still wants us to replicate every mess we ever made in > > the old command line. Would that be a smart choice? > > I venture to suggest that the deprecation policy leaves us enough > ambiguity that we could issue a deprecation warning saying something > suitably vague like "various quirks of the cli may change in incompatible > ways in future", and then just do a big-bang conversion to QAPI'ified > version. If there are known quirks that we intend to break we could > call them out, but if we accidentally change a few quirks without > realizing it, so be it. > > IOW, the big-bang conversion to QAPIified CLI is possible with our > deprecation policy, without having the maintain the existing code > in parallel with bug-for-bug compat. The main constraint is that > we would need to have a reasonable idea about when the QAPIified > CLI is likely to be ready to merge, so we have ability to warn > developers of forthcoming changes. I agree, that should be workable with our current deprecation policy. [If it is at all feasible, we should also warn explicitly if a known-quirky option is used, but the general warning should be enough, especially if we feature it prominently in QEMU release notes as well.]