[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 14/14] docs: document special exception for machine type depr
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH 14/14] docs: document special exception for machine type deprecation & removal |
Date: |
Thu, 2 May 2024 10:53:30 +0100 |
User-agent: |
Mutt/2.2.12 (2023-09-09) |
On Thu, May 02, 2024 at 11:47:40AM +0200, Thomas Huth wrote:
> On 01/05/2024 20.27, Daniel P. Berrangé wrote:
> > This extends the deprecation policy to indicate that versioned machine
> > types will be marked deprecated after 3 years, and then subject to
> > removal after a further 3 years has passed.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> > docs/about/deprecated.rst | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > index 7b8aafa15b..55120e774c 100644
> > --- a/docs/about/deprecated.rst
> > +++ b/docs/about/deprecated.rst
> > @@ -11,6 +11,18 @@ releases, the feature is liable to be removed.
> > Deprecated features may also
> > generate warnings on the console when QEMU starts up, or if activated via
> > a
> > monitor command, however, this is not a mandatory requirement.
> > +As a special exception to this general timeframe, rather than have an
> > +indefinite lifetime, versioned machine types are only intended to be
> > +supported for a period of 6 years, equivalent to 18 QEMU releases. All
> > +versioned machine types will be automatically marked deprecated after an
> > +initial 3 years (9 QEMU releases) has passed, and will then be deleted
> > after
>
> Should there be the word "period" after "3 years" ? Otherwise it sounds a
> little bit weird to me - but I'm also not a native speaker, so I might be
> wrong.
It would be valid to say either "3 year period" or "3 years", but
not "3 years period".
> > +a further 3 year period has passed. It is recommended that a deprecated
> > +machine type is only used for incoming migrations and restore of saved
> > state,
> > +for pre-existing VM deployments.
>
> Should we maybe add a sentence that they should ideally be updated to a
> newer machine type during a service window with downtime? (well, it might be
> also obvious, so maybe not worth to mention it)
Sure, I'm fine adding something about that, as it helps to steer people
in the sane direction.
> > Newly deployed VMs should exclusively use a
> > +non-deprecated machine type, with use of the most recent version highly
> > +recommended. Non-versioned machine types follow the general feature
> > +deprecation policy.
>
> Anyway:
> Reviewed-by: Thomas Huth <thuth@redhat.com>
>
With 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 :|
- Re: [PATCH 10/14] hw: set deprecation info for all versioned machine types, (continued)
- [PATCH 12/14] hw/ppc: remove obsolete manual deprecation reason string of spapr machines, Daniel P . Berrangé, 2024/05/01
- [PATCH 11/14] hw: skip registration of outdated versioned machine types, Daniel P . Berrangé, 2024/05/01
- [PATCH 13/14] hw/i386: remove obsolete manual deprecation reason string of i440fx machines, Daniel P . Berrangé, 2024/05/01
- [PATCH 14/14] docs: document special exception for machine type deprecation & removal, Daniel P . Berrangé, 2024/05/01
- Re: [PATCH 00/14] hw: define and enforce a standard lifecycle for versioned machines, Cédric Le Goater, 2024/05/03
- Re: [PATCH 00/14] hw: define and enforce a standard lifecycle for versioned machines, Peter Maydell, 2024/05/03