[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests — ci(python): declare the version tiers and the latest version in one file (#1660) #1677 is Part A; nothing else on this

• Followed the coding style (make pylint, make mypy, make isort) — pylint (W/E) and mypy clean on util/update_python_versions.py; test_isort_clean passes

• make test passes, and a test case covers the change — new module added; the seven affected tests/project modules run, not the whole suite

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

Part B of #1660: cron-python-versions.yml recomputes .github/python-versions.toml every Monday and proposes the change as a pull request (rulings A, B and C). Design choices to check:

• A fourth source, actions/runner-images' README, besides python.org's release cycle, PyPy's versions.json and setup-python's manifest: the manifest still lists retired images and cannot say which image ubuntu-latest is.
• Tiers only move forward: a version enters as supported, moves to KTLO, then is dropped. An end-of-life version the file does not list is never added.
• A pre-release is held back as a notice, since load() refuses that tier until a workflow runs non-blocking pre-release legs.
• Audit failures are listed, not blocking: detect runs the three audit modules on the rewritten tree, and the body lists what failed, to finish by hand on the branch.
• No repeat proposals: while bot/python-versions has an open pull request, detect reads every commit it holds ahead of main (a commits-only fetch, so merges of main are seen through and left out), and tiers already proposed there, hand edits on top or not, get no second push or approval. If the branch holds hand edits and proposes other tiers, detect fails rather than ask for an approval that publish would refuse.
• A merged or closed proposal's branch is stale: with no open pull request (delete_branch_on_merge is off), detect proposes afresh and publish recreates the branch from main. So a proposal closed unmerged comes back the next Monday. detect gains pull-requests: read to read that state.
• No workflow file is written: the App token has no workflows permission, so it cannot push one. Workflow comments name the tiers rather than restate them.
• Release counts follow the tag: once a version is tagged, version_check counts the wheels and conda builds in the tier file at the tag's commit. For v1.5.0b12, which predates the file, it uses the file as ci(python): declare the version tiers and the latest version in one file (#1660) #1677 added it. Merging a new supported version therefore no longer re-runs pypi for a finished release and fails fix(ci): Create Release tags main's tip at approval time, not the commit it was created for #1634's tag check.

One-time setup: add Pull requests: read and write to the release App, then accept the new permission on its installation.

First run, on today's sources: pypy3.12 joins the supported tier. The ruleset needs no edit, and the audit passes.

Tests: test_python_versions_update_1660.py holds 53 tests against 2026-10-13 snapshots of the four sources; every one fails or errors on main. test_release_tags_the_run_sha_1634.py gains a scratch-repository class for the release counts. The seven affected modules pass on 3.14 and 3.15, and on 3.8 and 3.10 where they do not skip. actionlint reports only what it already reports on main.

Part of #1660

[JarryShaw]

Verdict: GOOD TO GO at d2b0904df (rebased onto 9808d51d3). A Sonnet cross-review checked three rounds.

• Proposal tracking: detect sees a proposal anywhere on bot/python-versions, including behind a merge of main. On github.com, the commits-only fetch found all 5 commits of wip/443-gap-intervals; the old shallow fetch found 2. A real hand edit still blocks.
• Stale branch: a branch with no open PR is recreated from main.
• Tier counts: Create Release judges an already-tagged version against the tier file at its tag's commit. For v1.5.0b12, which predates the file, it uses the file as first added; that equals b12's hard-coded counts.
• Permissions: detect holds no secrets, only contents: read and pull-requests: read. The PR job mints the App token with exactly contents and pull-requests write, inside github-release.
• Tests: 344 across the seven modules on 3.14 and 3.15; the new module's 53 fail on main.
• Not verified: the token push, the approval flow and a real end-to-end run. Workflows may not be triggered from here, so the first scheduled run will show them.

Two behaviours need your decision before this merges:

1. A proposal you close without merging comes back the next Monday, with the github-release approval asked again each week.
   • Recommended: remember the fingerprint of a proposal closed unmerged, and re-propose only when the tiers change.
   • Alternative: keep as is.
2. A merge of main that carries conflict-resolution edits is treated 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.
   • Alternative: keep as is.

One-time setup: add Pull requests read and write to the pypcapkit-release App.

[github-actions]

Coverage: 89.47% (unit tier, Python 3.15, d2b0904df, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18860	954	2368	868	91.06%
pcapkit/corekit	2372	67	762	35	96.49%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	3035	151	1076	34	94.28%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17166	226	4580	190	98.07%
pcapkit/toolkit	1437	281	592	6	77.97%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4417	2342	1010	157	43.38%

Per-file detail: the coverage-html artifact of this run.