From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>
Subject: [Qemu-devel] [PATCH v2 2/2] docs: document support lifetime for features
Date: Tue, 6 Jun 2017 12:05:56 +0100 [thread overview]
Message-ID: <20170606110556.12922-3-berrange@redhat.com> (raw)
In-Reply-To: <20170606110556.12922-1-berrange@redhat.com>
There is currently no explicit guidance on the duration of support
for features such as versioned machine types, which have a finite
useful lifespan. Thus apps / users cannot predict how much time
they might be able to use a feature for, before it is removed (if
ever).
This adds a new appendix that lists items which have finite lifecycles,
such as machine types. For items which are generally expected to be
supported indefinitely, it sets out the policy around deprecation
and removal, should it be needed.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
---
qemu-doc.texi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 29f89d8..e3c6400 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -37,6 +37,7 @@
* QEMU Guest Agent::
* QEMU User space emulator::
* Implementation notes::
+* Support lifetime::
* Deprecations::
* License::
* Index::
@@ -3017,6 +3018,39 @@ Run the emulation in single step mode.
@include qemu-tech.texi
+@node Support lifetime
+@appendix Support lifetime
+
+Features provided by QEMU are subject to varying support lifetimes.
+
+In general features are intended to be supported indefinitely once
+introduced. In the event that a feature needs to be removed, there
+will be some period in which it will be marked as deprecated before
+eventual removal. All deprecated features will be listed in the
+``Deprecations'' appendix of this document. They may also generate
+warnings on the console when QEMU starts up, or if activated via
+a monitor command.
+
+Certain features will have an inherently finite lifetime, and thus
+will be removed on a fixed schedule.
+
+@node Machine types
+@section Machine types
+
+For architectures which aim to support live migration compatibility
+across releases, each release will introduce a new versioned machine
+type. For example, the 2.8.0 release introduced machine types
+``pc-i440fx-2.8'' and ``pc-q35-2.8' 'for the x86_64/i686 architectures.
+
+To allow live migration of a guest running on a 2.8.0 release to a
+2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and
+``pc-q35-2.8''. To allow users live migrating VMs to skip multiple
+intermediate releases when upgrading, new releases of QEMU will
+support machine types from many previous versions.
+
+The supported lifetime for machine types is 12 releases, which is
+equivalent to 4 years worth of previous QEMU releases.
+
@node Deprecations
@appendix Deprecations
--
2.9.3
next prev parent reply other threads:[~2017-06-06 11:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 11:05 [Qemu-devel] [PATCH v2 0/2] Document deprecated features & support lifecycle Daniel P. Berrange
2017-06-06 11:05 ` [Qemu-devel] [PATCH v2 1/2] docs: document deprecated features in appendix Daniel P. Berrange
2017-06-23 11:44 ` Markus Armbruster
2017-06-23 11:49 ` Daniel P. Berrange
2017-06-06 11:05 ` Daniel P. Berrange [this message]
2017-06-23 11:48 ` [Qemu-devel] [PATCH v2 2/2] docs: document support lifetime for features Markus Armbruster
2017-06-23 11:54 ` Daniel P. Berrange
2017-06-23 12:19 ` Peter Maydell
2017-06-06 14:04 ` [Qemu-devel] [PATCH v2 0/2] Document deprecated features & support lifecycle Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170606110556.12922-3-berrange@redhat.com \
--to=berrange@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).