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 <ehabk...@redhat.com> > > > --- > > > 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 :|
