8:07 a.m.
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