docs(python-versions): add 3.14 to the supported set - #292
Conversation
3.14 reached stable release in October 2025, so the policy's stated reason for excluding it expired roughly ten months ago. The exclusion was stale, not deliberate: the paragraph justifying it used 3.14 as its own example of a pre-release, and nobody revisited the sentence when the example shipped. The gap was already being violated in practice and the enforcement could not see it. cyo-adventure passes python-version '3.14' to python-sonarcloud.yml today, but check-python-versions.sh scans only this repo's workflows and templates, never consumer repos, so a consumer can select an unsupported version indefinitely without tripping anything. Adding a version is permissive. The checker fails on versions outside the set, so widening it cannot break an existing workflow, change a matrix, or move a default. primary stays 3.12, since that is the version that actually builds and runs analysis and moving it is the change with real blast radius. Rewrote the pre-release paragraph to state the rule without naming a version, which is the failure mode that produced this drift, and added a note that the set is a permit list so future readers can see that adding is cheap and removing is not. Verified: check-python-versions.sh rc=0 and reports the parsed set as [3.10 3.11 3.12 3.13 3.14]; pre-commit clean.
|
Warning Review limit reached
Next review available in: 30 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Pull request overview
Updates the organization’s Python version policy documentation to include Python 3.14 in the supported set, while keeping 3.12 as the primary default. This repo acts as the single source of truth for reusable workflow version policy, so documentation accuracy and consistent terminology are important.
Changes:
- Add Python 3.14 to the
python-versions:supportedmarker and the policy table. - Rewrite the pre-release guidance to avoid embedding a specific version example.
- Clarify that the supported set is permissive (allows selection), not prescriptive (does not force matrices to include it).
| | Primary | 3.12 | Default for single-version `python-version` inputs and the version quality checks run on | | ||
| | Supported matrix | 3.10, 3.11, 3.12, 3.13 | Comprehensive test matrix | | ||
| | Supported matrix | 3.10, 3.11, 3.12, 3.13, 3.14 | Comprehensive test matrix | | ||
| | PR fast tier | 3.11, 3.12 | Subset for fast PR feedback; must be a subset of the supported matrix | |
| The supported set is a permit list, not a mandate. `check-python-versions.sh` | ||
| fails on a version *outside* the set, so adding a version only widens what | ||
| workflows may select; it does not add that version to any matrix or change any |
What
Adds
3.14topython-versions:supportedin docs/python-versions.md.primarystays3.12.Why now
The exclusion was stale, not deliberate. The policy justified it in its own words:
The rule is sound. Its worked example expired: 3.14 reached stable release in October 2025,
about ten months ago. The sentence used the very version it was excluding as its
illustration, so it silently became self-contradicting the moment that version shipped, and
nobody revisited it.
It is already being violated where the checker cannot see it.
cyo-adventurepassespython-version: '3.14'topython-sonarcloud.ymltoday.check-python-versions.shscansonly this repo's
.github/workflows/*.ymlandworkflow-templates/*.yml, never consumerrepos, so a consumer can select an unsupported version indefinitely without tripping
anything. The choice is not whether to allow 3.14, it is whether to ratify what is already
running or keep a policy the enforcement cannot enforce.
It unblocks correct
sonar-python-versionvalues. With #291 merged, each consumer shoulddeclare every version its
requires-pythonadmits. Four of six need 3.14 to do that withoutviolating policy:
requires-python>=3.10,<3.153.10,3.11,3.12,3.13,3.14>=3.10,<3.153.10,3.11,3.12,3.13,3.14>=3.11,<3.153.11,3.12,3.13,3.14>=3.113.11,3.12,3.13,3.14Blast radius: none
The supported set is a permit list.
check-python-versions.shfails on a version outsidethe set, so widening it cannot break an existing workflow, alter a matrix, or move a default.
No workflow selects 3.14, so nothing changes behaviour on merge.
primaryis untouched,which is the entry that would carry real risk, since it is the version that actually builds
and runs analysis.
Also in this change
Rewrote the pre-release paragraph to state the rule without naming a version, since naming
one is exactly the failure mode that produced this drift. Added a note that the set is a
permit list, so a future reader can see that adding is cheap and removing is not.
Verification
scripts/check-python-versions.shrc=0, reporting the parsed set as[3.10 3.11 3.12 3.13 3.14]pre-commit run --all-filescleanOut of scope
Python 3.10 goes EOL in October 2026. Removing it is the restrictive direction and has real
blast radius: MTG_AI and python-libs both declare
requires-python = ">=3.10", so theirfloors have to move first. That belongs in its own sequenced change, not here.