Skip to content

Commit 866eb28

Browse files
committed
Document cross-project Python support policy
Signed-off-by: Ihar Hrachyshka <[email protected]>
1 parent d45f91e commit 866eb28

File tree

1 file changed

+65
-0
lines changed

1 file changed

+65
-0
lines changed

docs/python-version-support.md

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# Python Version Support
2+
3+
This document describes the project Python version support policy.
4+
5+
## Goals
6+
7+
1. Ensure that the project is compatible with latest Python releases.
8+
2. Ensure that the project is compatible with the latest Python LTS releases.
9+
3. Ensure reasonable choice of Python versions for users to choose from.
10+
4. Ensure that CI and engineering resources are not wasted on supporting
11+
outdated Python versions.
12+
13+
## Approach
14+
15+
### Minimal Python version
16+
17+
The minimal Python version to support in all projects is determined based on
18+
the availability of Python versions in popular operating systems (Fedora,
19+
Debian, MacOS) and products built on top of the packages (RHEL AI).
20+
21+
At the moment of writing, the minimal Python version that all projects should
22+
support is 3.11.
23+
24+
### Support multiple Python versions
25+
26+
To accommodate users that are not willing to upgrade to the latest Python
27+
version, projects should strive to support all (upstream Python
28+
versions)[https://devguide.python.org/versions/] in some capacity. At the very
29+
least, all projects should run lightweight tests (unit, functional) against all
30+
versions from the minimal supported version up to the latest version.
31+
32+
At the moment of writing, the versions to support are: 3.11, 3.12, 3.13.
33+
34+
### Dominant Python version
35+
36+
To concentrate resources on the most used Python version, the project should
37+
pick one Python version that will be used to run all CI jobs. Other Python
38+
versions may be supported in a more limited capacity (e.g. only running unit
39+
tests).
40+
41+
In general, there's a single dominant Python version at any given time. During
42+
adoption of a new dominant version, the project may have to temporarily support
43+
two dominant versions at the same time. This is a temporary situation and plans
44+
should be made to get back to the single dominant version as soon as possible,
45+
to avoid wasting resources.
46+
47+
At the moment of writing, the dominant Python version is 3.11.
48+
49+
### Drop support for old Python versions
50+
51+
To avoid wasting resources on supporting outdated Python versions, projects
52+
should proactively drop support for old versions below the minimal Python
53+
version indicated above.
54+
55+
To drop support for a Python version, projects should remove all tests that are
56+
specific to this version. They should also update `pyproject.yaml` metadata to
57+
specify the minimal Python version equal to the one indicated above.
58+
Documentation should be updated to reflect the new minimal version, if needed.
59+
60+
At the moment of writing, the versions to drop support for are: 3.10 or
61+
earlier.
62+
63+
## Links
64+
65+
- [Upstream status of Python versions](https://devguide.python.org/versions/)

0 commit comments

Comments
 (0)