| Message ID | 20240501182759.2934195-15-berrange@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | hw: define and enforce a standard lifecycle for versioned machines | expand |
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. > +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) > 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>
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
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 +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. 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. + Prior to the 2.10.0 release there was no official policy on how long features would be deprecated prior to their removal, nor any documented list of which features were deprecated. Thus
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(+)