docs: describe the support policy for python versions

Bug: https://github.com/mesonbuild/meson/issues/14322
pull/14325/head
Eli Schwartz 2 months ago
parent 8cc1a394b5
commit e132a60ad1
No known key found for this signature in database
GPG Key ID: CEB167EFB5722BD6
  1. 51
      docs/markdown/Contributing.md
  2. 18
      docs/markdown/FAQ.md

@ -501,11 +501,58 @@ those are simple.
- indent 4 spaces, no tabs ever - indent 4 spaces, no tabs ever
- brace always on the same line as if/for/else/function definition - brace always on the same line as if/for/else/function definition
## External dependencies ## Dependency support policy
The goal of Meson is to be as easily usable as possible. The user The goal of Meson is to be as easily usable as possible. The user
experience should be "get Python3 and Ninja, run", even on experience should be "get Python3 and Ninja, run", even on
Windows. Unfortunately this means that we can't have dependencies on Windows.
Additionally, Meson is popularly used in many core infrastructure packages in a
Unix (and particularly, Linux) userland. This includes:
- package managers, such as pacman (Arch Linux) and portage (Gentoo)
- init systems (systemd, openrc, dinit)
- graphics stacks (xorg, wayland, libdrm, Mesa, gtk)
As such it needs to be able to run early on when bootstrapping a system from
scratch.
### Python
We will always support all non EOL versions of CPython. Yes, there are people
out there using and depending on every old version of python. In fact, there
are people using and depending on systems that had a brand new python at the
time of release, but with a much longer support cycle than Python itself. We
need to balance the tradeoff between supporting those systems and being able to
improve our own codebase and code quality.
Meson will also be *honest* about what versions of python it supports. When a
version of CPython becomes EOL, it becomes eligible to be removed from our
support policy. We cannot guarantee continued support forever for software that
is not supported by its own developers, even if some deprecated LTS systems out
there still ship it. However, that doesn't mean we will drop support for those
versions simply because they are old. If we are not using new functionality
from new python versions, we will continue to mark Meson as compatible with the
older version -- and test it in CI!
(Note that contrary to popular belief, it is actually easier to test support
for very old versions of python than it is to drop support for it. We already
have the CI setup necessary for testing. Upgrading the CI to use newer versions
of python, on the other hand, represents mildly painful administrative work
that has to be done.)
So, in order to start requiring a newer version of python, one should check a
few factors:
- are the older versions being dropped, already EOL? [Python EOL chart](https://endoflife.date/python)
- document the new minimum version of corresponding OSes
- rationalize the benefit of the change in terms of improvements to development
and maintenance of Meson. What new language features will be unlocked by the
upgrade, that Meson will be able to make good use of? Not every version has
new features requiring an upgrade, and not every new feature is so great we
need to drop everything to use it
### External dependencies
Unfortunately this also means that we can't have dependencies on
projects outside of Python's standard library. This applies only to projects outside of Python's standard library. This applies only to
core functionality, though. For additional helper programs etc the use core functionality, though. For additional helper programs etc the use
of external dependencies may be ok. If you feel that you are dealing of external dependencies may be ok. If you feel that you are dealing

@ -333,6 +333,24 @@ that could fulfill these requirements:
Out of these we have chosen Python because it is the best fit for our Out of these we have chosen Python because it is the best fit for our
needs. needs.
## Do you at least support my ancient python install?
Yes! :) We have a relatively sedate version support policy. You can read about
it in the [Contributing documentation](Contributing.md#python)
We are also willing to support old versions of meson as LTS releases,
particularly, if it is the final version to support a given python version. If
you have a use case, please discuss it with us and be willing to help backport
bug fixes.
- python 3.5: [supported through Meson 0.56.2](Release-notes-for-0.56.0.md#python-35-support-will-be-dropped-in-the-next-release)
- python 3.6: [supported through Meson 0.61.5](Release-notes-for-0.61.0.md#python-36-support-will-be-dropped-in-the-next-release)
- python 3.7: currently actively supported by Meson
We encourage projects to support a wide range of Meson versions if they are not
actually using the latest features anyway. In many, many cases it is quite
practical to support e.g. Meson 0.61.
## But I really want a version of Meson that doesn't use python! ## But I really want a version of Meson that doesn't use python!
Ecosystem diversity is good. We encourage interested users to write this Ecosystem diversity is good. We encourage interested users to write this

Loading…
Cancel
Save