Re: [Qemu-devel] release retrospective, next release timing, numbering

[Cornelia Huck]

On Wed, 2 May 2018 09:16:32 +0100
Daniel P. Berrangé <address@hidden> 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.]