Thomas Huth <th...@redhat.com> writes: > Our distro support policy has been written with a best-effort > estimation of what users and developers need. However, as we now > know, the support for older long-term distributions can get really > troublesome for upstream development, since it is for example close > to impossible to keep the code for all Python versions maintained, > especially if upstream projects dropped support a longer time ago > already (Python 3.6 has been EOL at the end of 2021) while it is > still the main version of some long-term distros (CentOS/RHEL 8 and > openSUSE/SLES 15). > The QEMU project only has a limited amount of people working on > the development, so we just cannot afford of supporting both, very > old and the latest versions of our dependencies without burning > the few people who are working on those topics. So we *have* to > refine our support statement instead: > > 1) Once a new major version has been released, it should be enough > to limit the support for the previous major versions to one year > instead of two. One year should be enough time to get all people > who are interested in following the development of QEMU and who would > like to use the latest and greatest version of QEMU to upgrade their > system to the next major release of their distribution. All others > are likely happy with the old version of QEMU that is provided by > their distributor anyway and thus likely won't try to compile the > latest and greatest version of QEMU on their system. > > 2) For long-term distributions that release a new version only very > seldom, we limit the support to four years after the initial release. > > Note: These changes mean that openSUSE is not considered as supported > anymore (since version 15.0 has been released in May 2018), and > RHEL/CentOS 8 will not be supported anymore in 3 months (since version > 8.0 has been released in May 2019). > > Signed-off-by: Thomas Huth <th...@redhat.com> > --- > docs/about/build-platforms.rst | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst > index 1c1e7b9e11..cdc38f16a4 100644 > --- a/docs/about/build-platforms.rst > +++ b/docs/about/build-platforms.rst > @@ -67,10 +67,11 @@ Non-supported architectures may be removed in the future > following the > Linux OS, macOS, FreeBSD, NetBSD, OpenBSD > ----------------------------------------- > > -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. In this context, third-party efforts to extend the lifetime of a > distro > +The project aims to support the most recent major version at all times for > +up to four years after its initial release. Support for the previous major > +version will be dropped one years after the new major version is released
"one year" (singular) Suggest "the next major version". > +or when the vendor itself drops support, whichever comes 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); > the same is true of repositories that contain packages backported from later > releases (e.g. Debian backports). Within each major release, only the most If we take Paolo's "[RFC PATCH] docs: build-platforms: refine requirements on Python build dependencies", then the rationale for this one becomes weaker. But I believe it's well worth serious consideration all the same. Why would we *not* want to do what Thomas proposes?