Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> --- 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";>libvirt</a></li> - <li><a href="https://repology.org/metapackage/qemu/versions";>qemu</a></li> - <li><a href="https://repology.org/metapackage/qemu-kvm/versions";>qemu-kvm</a></li> - </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
