What:
Currently, all our python modules and programs only request python 3.11 or later. Python 3.11 is old, now.
Even if there still are security releases, it's going to be a limiting factor to stick with that old a version. It's time to increase the required version.
Expected:
The python code requires a python version that:
- is still maintained,
- brings interesting features (very subjective),
- gives enough time before we need to update again,
- is widely available in common systems (e.g. Debian, Ubuntu, Fedora).
Proposal:
Increase requirement to python version 3.14 or later:
- it is the latest stable version
- it will have generic bug fixes until 2027-10-05
- it will have security fixes until 2030-10-01
- it is widely available:
- Ubuntu 26.04 has 3.14.3
- Fedora 44 has 3.14.4
- Buildroot has 3.14.5
- Yocto has 3.14.5
- drawbacks:
- Debian 13 Trixie only has 3.13.9 :-(
Tasks:
- strictly required:
- update the projects requierments
- fix new linter errors (e;g. black will find more issues in existing code)
- where they exist, ensure tests still succeed; fix the code and/or the test appropriately
- nice to have:
- update existing code to new features availqble with python 3.14
Contingency plan:
Apart from linter errors, there are no blocking issues identified that would prevent existing code to work with a newer Python version. If that proves to be wrong and an insurmontable issue arises, the contingency plan is thus relatively simple: do not merge the branch.
If issues are detected after the branch is merged, they shall be considered regressions and fixed. There will be no walking back after the merge.
What:
Currently, all our python modules and programs only request python 3.11 or later. Python 3.11 is old, now.
Even if there still are security releases, it's going to be a limiting factor to stick with that old a version. It's time to increase the required version.
Expected:
The python code requires a python version that:
Proposal:
Increase requirement to python version 3.14 or later:
Tasks:
Contingency plan:
Apart from linter errors, there are no blocking issues identified that would prevent existing code to work with a newer Python version. If that proves to be wrong and an insurmontable issue arises, the contingency plan is thus relatively simple: do not merge the branch.
If issues are detected after the branch is merged, they shall be considered regressions and fixed. There will be no walking back after the merge.