8:07 a.m.
This makes our platform support policy easier to grasp, and also
explicitly allows us to drop Debian 9, which is EOL as of last week.
Andrea Bolognani (5):
docs: platforms: Add brief outline
docs: platforms: Convert to reStructuredText
docs: platforms: Simplify support policy
docs: platforms: Clarify stance on third-party LTS efforts
docs: platforms: Mention Windows API target
docs/platforms.html.in | 115 -----------------------------------------
docs/platforms.rst | 85 ++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+), 115 deletions(-)
delete mode 100644 docs/platforms.html.in
create mode 100644 docs/platforms.rst
--
2.25.4
8:07 a.m.
New subject: [libvirt PATCH 1/5] docs: platforms: Add brief outline
This will make the document look nicer, especially after we have
converted it to reStructuredText.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/platforms.html.in | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/docs/platforms.html.in b/docs/platforms.html.in
index 5c90f1dd7a..c50279bffd 100644
--- a/docs/platforms.html.in
+++ b/docs/platforms.html.in
@@ -6,12 +6,16 @@
<ul id="toc"></ul>
+ <p>
+ Libvirt aims to support building and executing on multiple host OS
+ platforms, as well as working with multiple hypervisors. This document
+ outlines which platforms are targeted for each of these areas.
+ </p>
+
<h2>Build targets</h2>
<p>
- Libvirt drivers aim to support building and executing on multiple
- host OS platforms. This document outlines which platforms are the
- major build targets. These platforms are used as the basis for deciding
+ These platforms are used as the basis for deciding
upon the minimum required versions of 3rd party software libvirt depends
on. If a platform is not listed here, it does not imply that libvirt
won't work. If an unlisted platform has comparable software versions
--
2.25.4
8:07 a.m.
New subject: [libvirt PATCH 2/5] docs: platforms: Convert to reStructuredText
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/platforms.html.in | 119 -----------------------------------------
docs/platforms.rst | 100 ++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 119 deletions(-)
delete mode 100644 docs/platforms.html.in
create mode 100644 docs/platforms.rst
diff --git a/docs/platforms.html.in b/docs/platforms.html.in
deleted file mode 100644
index c50279bffd..0000000000
--- a/docs/platforms.html.in
+++ /dev/null
@@ -1,119 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
- <body>
- <h1>Supported host platforms</h1>
-
- <ul id="toc"></ul>
-
- <p>
- Libvirt aims to support building and executing on multiple host OS
- platforms, as well as working with multiple hypervisors. This document
- outlines which platforms are targeted for each of these areas.
- </p>
-
- <h2>Build targets</h2>
-
- <p>
- These platforms are used as the basis for deciding
- upon the minimum required versions of 3rd party software libvirt depends
- on. If a platform is not listed here, it does not imply that libvirt
- won't work. If an unlisted platform has comparable software versions
- to a listed platform, there is every expectation that it will work.
- Bug reports are welcome for problems encountered on unlisted platforms
- unless they are clearly older vintage than what is described here.
- </p>
-
- <p>
- Note that when considering software versions shipped in distros as
- support targets, libvirt considers only the version number, and assumes
- the features in that distro match the upstream release with the same
- version. In other words, if a distro backports extra features to the
- software in their distro, libvirt upstream code will not add explicit
- support for those backports, unless the feature is auto-detectable in
- a manner that works for the upstream releases too.
- </p>
-
- <p>
- The Repology site is a useful resource to identify currently shipped
- versions of software in various operating systems, though it does not
- cover all distros listed below.
- </p>
-
- <ul>
- <li><a
href="https://repology.org/metapackage/libvirt/versions">lib...
- <li><a
href="https://repology.org/metapackage/qemu/versions">qemu&l...
- <li><a
href="https://repology.org/metapackage/qemu-kvm/versions">qe...
- </ul>
-
-
- <h3>Linux OS</h3>
-
- <p>
- For distributions with frequent, short-lifetime releases, the project
- will aim to support all versions that are not end of life by their
- respective vendors. For the purposes of identifying supported software
- versions, the project will look at Fedora, Ubuntu, and openSUSE distros.
- Other short-lifetime distros will be assumed to ship similar software
- versions.
- </p>
-
- <p>
- For distributions with long-lifetime releases, the project will aim to
- support the most recent major version at all times. Support for the
- previous major version will be dropped 2 years after the new major
- version is released. For the purposes of identifying supported software
- versions, the project will look at RHEL, Debian, Ubuntu LTS, and SLES
- distros. Other long-lifetime distros will be assumed to ship similar
- software versions.
- </p>
-
- <h3>Windows</h3>
-
- <p>
- The project supports building with current versions of the MinGW
- toolchain, hosted on Linux.
- </p>
-
- <h3>macOS</h3>
-
- <p>
- The project aims to support the most recent major version
- at all times. Support for the previous major version will
- be dropped 2 years after the new major version is released.
- </p>
-
- <p>
- Note that to compile libvirt will require extra packages
- to be made available on the macOS host. It is recommended
- to use <a href="https://brew.sh/">HomeBrew</a> since this
- is what libvirt CI tests with, however, <a
herf="https://www.macports.org/">MacPorts</a>
- is an alternative option that is likely to work.
- </p>
-
- <h3>FreeBSD</h3>
-
- <p>
- The project aims to support the most recent major version
- at all times. Support for the previous major version will
- be dropped 2 years after the new major version is released.
- </p>
-
- <h2>Virtualization platforms</h2>
-
- <p>
- For <a href="drivers.html">hypervisor drivers</a> which
execute
- locally (QEMU, LXC, VZ, libxl, etc), the set of supported operating
- system platforms listed above will inform choices as to the minimum
- required versions of 3rd party libraries and hypervisor management
- APIs.
- </p>
- <p>
- If a hypervisor is not commonly shipped directly by any distro
- listed above, (VMware ESX, HyperV, VZ), the project aims to
- support versions up to 5 years, or until the vendor discontinues
- support, whichever comes first.
- </p>
-
- </body>
-</html>
diff --git a/docs/platforms.rst b/docs/platforms.rst
new file mode 100644
index 0000000000..2845ac40ea
--- /dev/null
+++ b/docs/platforms.rst
@@ -0,0 +1,100 @@
+========================
+Supported host platforms
+========================
+
+.. contents::
+
+Libvirt aims to support building and executing on multiple host OS platforms,
+as well as working with multiple hypervisors. This document outlines which
+platforms are targeted for each of these areas.
+
+
+Build targets
+=============
+
+These platforms are used as the basis for deciding upon the minimum required
+versions of 3rd party software libvirt depends on. If a platform is not listed
+here, it does not imply that libvirt won't work. If an unlisted platform has
+comparable software versions to a listed platform, there is every expectation
+that it will work. Bug reports are welcome for problems encountered on
+unlisted platforms unless they are clearly older vintage than what is described
+here.
+
+Note that when considering software versions shipped in distros as support
+targets, libvirt considers only the version number, and assumes the features in
+that distro match the upstream release with the same version. In other words,
+if a distro backports extra features to the software in their distro, libvirt
+upstream code will not add explicit support for those backports, unless the
+feature is auto-detectable in a manner that works for the upstream releases
+too.
+
+The `Repology`_ site is a useful resource to identify currently shipped
+versions of software in various operating systems, though it does not cover all
+distros listed below.
+
+* `libvirt on Repology`_
+* `qemu on Repology`_
+* `qemu-kvm on Repology`_
+
+Linux OS
+--------
+
+For distributions with frequent, short-lifetime releases, the project will aim
+to support all versions that are not end of life by their respective vendors.
+For the purposes of identifying supported software versions, the project will
+look at Fedora, Ubuntu, and openSUSE distros. Other short-lifetime distros
+will be assumed to ship similar software versions.
+
+For distributions with long-lifetime releases, the project will aim to support
+the most recent major version at all times. Support for the previous major
+version will be dropped 2 years after the new major version is released. For
+the purposes of identifying supported software versions, the project will look
+at RHEL, Debian, Ubuntu LTS, and SLES distros. Other long-lifetime distros will
+be assumed to ship similar software versions.
+
+Windows
+-------
+
+The project supports building with current versions of the MinGW toolchain,
+hosted on Linux.
+
+macOS
+-----
+
+The project aims to support the most recent major version at all times. Support
+for the previous major version will be dropped 2 years after the new major
+version is released.
+
+Note that to compile libvirt will require extra packages to be made available
+on the macOS host. It is recommended to use `HomeBrew`_ since this is what
+libvirt CI tests with, however, `MacPorts`_ is an alternative option that is
+likely to work.
+
+FreeBSD
+-------
+
+The project aims to support the most recent major version at all times. Support
+for the previous major version will be dropped 2 years after the new major
+version is released.
+
+
+Virtualization platforms
+========================
+
+For `hypervisor drivers`_ which execute locally (QEMU, LXC, VZ, libxl, etc),
+the set of supported operating system platforms listed above will inform
+choices as to the minimum required versions of 3rd party libraries and
+hypervisor management APIs.
+
+If a hypervisor is not commonly shipped directly by any distro listed above,
+(VMware ESX, HyperV, VZ), the project aims to support versions up to 5 years,
+or until the vendor discontinues support, whichever comes first.
+
+
+.. _HomeBrew: https://brew.sh/
+.. _MacPorts: https://www.macports.org/
+.. _Repology: https://repology.org/
+.. _hypervisor drivers: drivers.html
+.. _libvirt on Repology: https://repology.org/metapackage/libvirt/versions
+.. _qemu on Repology: https://repology.org/metapackage/qemu/versions
+.. _qemu-kvm on Repology: https://repology.org/metapackage/qemu-kvm/versions
--
2.25.4
8:07 a.m.
New subject: [libvirt PATCH 3/5] docs: platforms: Simplify support policy
We discuss Linux, FreeBSD and macOS separately, and we even go as
far as splitting Linux distros into short-lifetime and long-lifetime,
when ultimately the same two priciples apply everywhere: we don't
want to support a platform longer than its vendor does, and in cases
where the vendor support is extremely long we need to have a
time-based escape hatch.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/platforms.rst | 47 ++++++++++++++--------------------------------
1 file changed, 14 insertions(+), 33 deletions(-)
diff --git a/docs/platforms.rst b/docs/platforms.rst
index 2845ac40ea..702d8d56d3 100644
--- a/docs/platforms.rst
+++ b/docs/platforms.rst
@@ -36,46 +36,27 @@ distros listed below.
* `qemu on Repology`_
* `qemu-kvm on Repology`_
-Linux OS
---------
-
-For distributions with frequent, short-lifetime releases, the project will aim
-to support all versions that are not end of life by their respective vendors.
-For the purposes of identifying supported software versions, the project will
-look at Fedora, Ubuntu, and openSUSE distros. Other short-lifetime distros
-will be assumed to ship similar software versions.
-
-For distributions with long-lifetime releases, the project will aim to support
-the most recent major version at all times. Support for the previous major
-version will be dropped 2 years after the new major version is released. For
-the purposes of identifying supported software versions, the project will look
-at RHEL, Debian, Ubuntu LTS, and SLES distros. Other long-lifetime distros will
-be assumed to ship similar software versions.
-
-Windows
--------
-
-The project supports building with current versions of the MinGW toolchain,
-hosted on Linux.
-
-macOS
------
+Linux, FreeBSD and macOS
+------------------------
The project aims to support the most recent major version at all times. Support
for the previous major version will be dropped 2 years after the new major
-version is released.
+version is released or when the vendor itself drops support, whichever comes
+first.
-Note that to compile libvirt will require extra packages to be made available
-on the macOS host. It is recommended to use `HomeBrew`_ since this is what
-libvirt CI tests with, however, `MacPorts`_ is an alternative option that is
-likely to work.
+For the purposes of identifying supported software versions available on Linux,
+the project will look at CentOS, Debian, Fedora, openSUSE, RHEL, SLES and
+Ubuntu LTS. Other distros will be assumed to ship similar software versions.
-FreeBSD
+For FreeBSD, decisions will be made based on the contents of the ports tree;
+for macOS, `HomeBrew`_ will be used, although `MacPorts`_ is expected to carry
+similar versions.
+
+Windows
-------
-The project aims to support the most recent major version at all times. Support
-for the previous major version will be dropped 2 years after the new major
-version is released.
+The project supports building with current versions of the MinGW toolchain,
+hosted on Linux.
Virtualization platforms
--
2.25.4
8:07 a.m.
New subject: [libvirt PATCH 4/5] docs: platforms: Clarify stance on third-party LTS efforts
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/platforms.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/platforms.rst b/docs/platforms.rst
index 702d8d56d3..4fcb458635 100644
--- a/docs/platforms.rst
+++ b/docs/platforms.rst
@@ -42,7 +42,8 @@ Linux, FreeBSD and macOS
The project aims to support the most recent major version at all times. Support
for the previous major version will be dropped 2 years after the new major
version is released or when the vendor itself drops support, whichever comes
-first.
+first. In this context, third-party efforts to extend the lifetime of a distro
+are not considered, even when they are endorsed by the vendor (eg. Debian LTS).
For the purposes of identifying supported software versions available on Linux,
the project will look at CentOS, Debian, Fedora, openSUSE, RHEL, SLES and
--
2.25.4
8:07 a.m.
New subject: [libvirt PATCH 5/5] docs: platforms: Mention Windows API target
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/platforms.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/docs/platforms.rst b/docs/platforms.rst
index 4fcb458635..b0ce0c3737 100644
--- a/docs/platforms.rst
+++ b/docs/platforms.rst
@@ -59,6 +59,9 @@ Windows
The project supports building with current versions of the MinGW toolchain,
hosted on Linux.
+The version of the Windows API that's currently targeted is Vista / Server
+2008.
+
Virtualization platforms
========================
--
2.25.4
9:58 a.m.
On Tue, Jul 14, 2020 at 03:07:38PM +0200, Andrea Bolognani wrote:
This makes our platform support policy easier to grasp, and also
explicitly allows us to drop Debian 9, which is EOL as of last week.
Andrea Bolognani (5):
docs: platforms: Add brief outline
docs: platforms: Convert to reStructuredText
docs: platforms: Simplify support policy
docs: platforms: Clarify stance on third-party LTS efforts
docs: platforms: Mention Windows API target
Reviewed-by: Pavel Hrdina <phrdina(a)redhat.com>
1592
days inactive
1592
days old
6 comments
2 participants
participants (2)
-
Andrea Bolognani -
Pavel Hrdina