Compatibility and branching strategy

[winstonsung]

2026-07-24:

Branching strategy

We currently have these important branches:

• dev:
  The development branch.
  Mixed with the major refactoring codes ( ./src/ ) and the legacy, messy (non-src) codes.
  Also used to separate refactoring away from v0.1.x releases.
  All pull requests should points to this branch, including changes to the legacy, messy codes.
  All commits are expected to be cherry-picked by @winstonsung when needed, so that REL0_1 is in-sync with this branch.
• main:
  The Git ref pointing to the latest stable (release) version.
• REL0_1:
  For the development of the 0.1.x versions (non-src).
  Used for not making the major refactoring codes (src) part of the v0.1.x releases.
  All commits from the dev branch that modified the legacy codes (non-src) should be cherry-picked to this branch.
• deployed (currently v0.1.9.dev0 with several cherry-picks):
  The Git ref pointing to the currently on-production Git ref.

Compatibility strategy

Python release cycle

• feature:
  Before the first beta, the next full release can accept new features, bug fixes, and security fixes.
• prerelease:
  After the first beta, no new features can go in, but feature fixes (including significant changes to new features), bug fixes, and security fixes are accepted for the upcoming feature release.
• bugfix:
  Once a version has been fully released, bug fixes and security fixes are accepted. New binaries are built and released roughly every two months. This phase is also called maintenance mode or stable release.
• security:
  After two years (18 months for versions before 3.13), only security fixes are accepted and no more binaries are released. New source-only versions can be released as needed.
• end-of-life:
  Five years after a release, support ends. The release cycle is frozen; no further changes are allowed.

Which Python versions to support

• Current technical debts:
  We currently still support Python 3.11 (security) only because our production runs on it.
  • To-do:
    We should migrate the production to Python 3.13 or Python 3.14; because Python 3.14 was never tested, we should first go with Python 3.13.
• We should only support bugfix versions; which means we should drop support for security versions.

Current Python version status

Ver.	Status	First release	First security ver.	End of life	Support in SCAICT-uwu (commit hash and it happened on which branch)	Notes
3.15	prerelease	2026-10-01		2031-10	Not yet – Not yet
3.14	bugfix	2025-10-07	2027-10-01	2030-10	2026-07-24 – Not yet dev 1983e6b – REL0_1 cfd8a52 –
3.13	bugfix	2024-10-07	2026-10-01	2029-10	2026-01-13 – Not yet dev c24aad9 – REL0_1 v0.1.15 452dafc –
3.12	security	2023-10-02	2025-04-02	2028-10	2026-01-05 – Planned dev 792f393 – REL0_1 v0.1.14 2a0fa34 –
3.11	security	2022-10-24	2024-04-01	2027-10	2024-02-20 – Planned main v0.1.0 45c8927 –	First supported version
3.10	security	2021-10-04	2023-04-05	2026-10	Never

See also

• https://devguide.python.org/versions/
• https://endoflife.date/python