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é <berra...@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 <th...@redhat.com>


Reply via email to