ci: declare the Python version tiers in one file, so EOL and new releases are a one-line change

Python versions are spelled out separately across many files. #1645 touched 27 of them:

the matrices in unit-tests.yml, python-compatibility.yml, create-release.yml, cron-conda.yml and lint.yml
pyproject.toml classifiers
util/ci_timing.py
the docs and the bug-report template

Moving 3.11 to KTLO at its end of life, or adding 3.16 as a pre-release leg, means repeating that whole sweep, and PyPy and other distributions multiply it.

Proposal

One data file (e.g. .github/python-versions.json) lists, per implementation (CPython, PyPy, ...), the versions in each tier: supported (blocking), KTLO (non-blocking), and pre-release (non-blocking).
Workflows read it. Each workflow builds its matrix from that file through a small matrix job and fromJSON. Required-check names stay stable.
A test pins the rest to it: classifiers, docs version lists, and the bug template.
A scheduled job compares the file with python.org's release-cycle data and PyPy's releases, and opens an issue when a version reaches end of life or a new pre-release appears.

A tier change then becomes a one-line edit plus a ruleset update.

Blocked until #1645 merges, because both edit every matrix.

Two updates.

Scope, from the owner in chat: the scheduled check also watches whether GitHub-hosted runners still provide each version, not just python.org's release cycle. setup-python's versions-manifest.json lists builds per Ubuntu release, and those runner images get retired. When no hosted image can provide a version any more, it leaves the GHA matrix. 3.6 is the current case: its only builds target ubuntu-18.04 and 20.04, both retired, so it stays out of KTLO.

Still blocked, now on two PRs that edit the same matrices: #1656 (create-release.yml), and the 3.7 KTLO follow-up to #1645 (unit-tests.yml, python-compatibility.yml), which is being written. This starts once both have merged.

One more scope item, from the owner in chat: jobs that run on a single interpreter (the gates, the full suite, coverage, lint, docs) always use the newest supported version. #1661 moves them to 3.15 now. The tier file here should then define that "latest" pointer, so the next bump moves them too.

Still blocked, now only on the 3.7 KTLO PR for #1633, which is being written. #1656 has merged.

Scope update, from the owner in chat: #1661 is folded in here.

The tier file also names the latest supported version.
Every job that runs on a single interpreter (the gates, the full suite, coverage, lint, docs, timing, the crons and the release helpers) reads that pointer instead of pinning a version.
A test audits that no job pins a version outside the file.
The scheduled monitor proposes the bump when a new release becomes supported.

That makes 3.15 for those jobs the first change made through the file. #1661's inventory of the pins, with whether each job's dependencies install on 3.15, will be posted here when it lands.

The 3.7 KTLO change is now #1665. This stays blocked until it merges.

Unblocked: #1665 has merged. A worker has Part A: the tier file with a latest pointer, workflows that read it, and tests that audit it. Job and required-check names stay identical. The monitor (Part B) comes in a follow-up, so its PR will say Part of #1660.

The #1661 inventory is carried into Part A. Every single-interpreter job moves to 3.15 except these, each recorded with its reason:

lint stays on 3.14. Under 3.15, pylint 4.1.3 / astroid 4.3.4 crashes on pcapkit/toolkit/dpkt.py (F0002), and E1101 goes from 12 to 35. bandit, mypy and vermin give the same results on both versions.
conda's setup-miniconda != '3.15' (conda has no py315 build), engine-tests' KTLO 3.10 step, and pypcap-parity's APT_CACHE_SAVE == '3.11'.

What was measured on 3.15:

The docs build, the vendor regeneration, conda-dist, the sdist (sha256-identical to 3.14's), make_samples and all 11 unittest-ordering cells match 3.14.
CI's 3.15 unit leg has a median of 9.3 min against the 45 min cap.
The gate's full suite was not run.

What needs my decision?

One thing: which Python lint runs on. The details are on #1677 (the PR for Part A). Lint is the only single-interpreter job not moving to 3.15, because on 3.15 pylint 4.1.3 / astroid 4.3.4 crashes on pcapkit/toolkit/dpkt.py and its E1101 count moves from 12 to 35. bandit, mypy and vermin agree on both versions.

Lint on 3.15, with only pylint held on 3.14 until astroid handles 3.15 (recommended).
Lint entirely on 3.15, accepting pylint's crash and the changed counts.
Keep lint on 3.14.

What needs my decision?

Two behaviours of the auto-updater, first raised on #1716, which merged with today's behaviour in place:

A proposal you close without merging comes back the next Monday, and asks for the github-release approval again each week.
- Recommended: remember a fingerprint of the closed proposal, and propose again only when the tiers change.
- Or keep it as is.
A merge of main into bot/python-versions that carries conflict-resolution edits counts as a plain merge, so a later publish would overwrite those edits.
- Recommended: treat a merge whose tree differs from a clean merge as a hand edit, which blocks publish.
- Or keep it as is.

Not a decision, but a one-time step only you can take: add Pull requests: read and write to the pypcapkit-release App, then accept the permission on its installation. The first scheduled run needs it.

Nothing else is waiting on you here. The GraalPy and free-threaded experimental tier (option 1) starts next.

done

Recorded: the pypcapkit-release App has Pull requests read and write, so the first scheduled run can open its proposal. The two behaviours above (a closed proposal returning each Monday, and conflict edits in a merge of main) still need your call. The recommended options are listed with each.

keep as is
if the conflict-resolution edits are necessary for the code to run, i say we keep the current logic. they're fine to tbe overwritten if they're no longer needed.

Recorded, both as they are now, so the updater needs no change:

A proposal closed without merging comes back the next Monday.
A merge of main into bot/python-versions counts as a plain merge, so a later publish may overwrite its conflict edits. Those edits are fine to lose once they are no longer needed.

This leaves only the experimental tier (GraalPy, free-threaded CPython), which is in its second review round.

ci(python): run GraalPy and free-threaded CPython as experimental, no…

Every part of this has landed:

ci(python): declare the version tiers and the latest version in one file (#1660) #1677: one tier file, which every matrix, classifier and docs list reads.
ci(python): a weekly job keeps the Python version tiers current and opens a PR (#1660) #1716: the weekly updater, which opens a PR.
ci(python): run GraalPy and free-threaded CPython as experimental, non-blocking test legs (#1660) #1725: the experimental tier for GraalPy and free-threaded CPython (option 1).

Promoting the experimental legs needs them green first, and that work is now tracked in #1731 (two 3.14t test failures) and #1732 (GraalPy reaches 26% of the suite before its cap, decision needed). Closing.

fix(conda): build each macOS conda package on its own architecture (#…

Navigation Menu

Repository navigation

ci: declare the Python version tiers in one file, so EOL and new releases are a one-line change #1660

25 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

ci: declare the Python version tiers in one file, so EOL and new releases are a one-line change #1660

Description

Activity

JarryShaw commented on Oct 13, 2026

JarryShaw commented on Oct 13, 2026

JarryShaw commented on Oct 13, 2026

JarryShaw commented on Oct 13, 2026

JarryShaw commented on Oct 13, 2026

JarryShaw commented on Oct 13, 2026

JarryShaw commented on Oct 13, 2026

25 remaining items

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions