Re: [Qemu-devel] [PATCH 1/3] qapi: SupportStatusInfo struct

[Daniel P . Berrangé]

On Thu, Apr 25, 2019 at 02:42:08PM -0300, Eduardo Habkost wrote:
> On Thu, Apr 25, 2019 at 11:20:58AM -0300, Wainer dos Santos Moschetta wrote:
> > Hi Eduardo,
> > 
> > 
> > On 04/23/2019 06:22 PM, Eduardo Habkost wrote:
> > > This struct will be used to represent support and deprecation
> > > status of QEMU features.
> > > 
> > > Signed-off-by: Eduardo Habkost <address@hidden>
> > > ---
> > >   qapi/common.json | 24 ++++++++++++++++++++++++
> > >   1 file changed, 24 insertions(+)
> > > 
> > > diff --git a/qapi/common.json b/qapi/common.json
> > > index 99d313ef3b..b59d0dc66b 100644
> > > --- a/qapi/common.json
> > > +++ b/qapi/common.json
> > > @@ -193,3 +193,27 @@
> > >                'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
> > >                'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
> > >                'x86_64', 'xtensa', 'xtensaeb' ] }
> > > +
> > > +##
> > > +# @SupportStatusInfo:
> > > +#
> > > +# Information on support status of a given feature
> > > +# (e.g. machine type)
> > > +#
> > > +# @deprecated: if true, the given feature is deprecated and may be 
> > > removed
> > > +#              in future versions of QEMU according to the QEMU 
> > > deprecation
> > > +#              policy.
> > 
> > Eventually management software will need the know the QEMU version the
> > feature is planed for removal. So makes sense to include a field to capture
> > that information as well or do you expect it to be added (as a good
> > practice) in the 'status-message'?
> 
> If we really want to provide extra information like version
> numbers, adding a separate field sounds better than using
> status-message.
> 
> But I'm not sure we really want to include this amount of detail
> in the API.  Mentioning explicit version numbers could make
> things more complex for downstream distributions of QEMU that
> include backports and/or have a different deprecation policy.
> 
> I'd like to hear opinions from others.

Yeah, I'm *not* in favour of mentioning any version number in this. Our
"2 cycle" deprecation rule is more of a guideline than a strict rule.
It can be extended if we find some blocking problem that makes removal
more painful than expected.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|