Background
.github/workflows/run-tests.yml runs the test job on a matrix of [ubuntu-latest, macos-latest, windows-latest] × ['3.11', '3.12', '3.13'] (line 60-62), but the lint job pins Python 3.11 only (line 22). New deprecation warnings or syntax changes that fire on 3.12 or 3.13 only would slip past lint.
See CODEBASE_CRITIQUE.md §8 (Dependencies and tooling, "Finding (Medium) — CI lint job pins Python 3.11 only; test matrix is 3.11/3.12/3.13").
Suggested approach
Either:
-
Add a Python-version matrix to the lint job:
lint:
name: Lint rms-picmaker (${{ matrix.python-version }})
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ['3.11', '3.12', '3.13']
fail-fast: false
steps:
- uses: actions/checkout@v6
- uses: actions/setup-python@v6
with:
python-version: ${{ matrix.python-version }}
...
-
Or move ruff check / mypy / pip-audit / sphinx-build / pymarkdown into the existing test matrix. This bundles three jobs into one (cheaper), but loses the ability to run lint in parallel with tests.
Approach #1 keeps the existing structure and adds two extra lint runs (~30 s each). Approach #2 simplifies the workflow but couples lint to test cell health.
Recommended
Approach #1 — keeps lint a fast, independent gate while still covering every supported Python version. The cost is small and the failure modes are easier to diagnose (a lint failure on 3.13 doesn't block the 3.11 test cell from running).
Acceptance criteria
Related
CODEBASE_CRITIQUE.md §8 — original finding.
Background
.github/workflows/run-tests.ymlruns the test job on a matrix of[ubuntu-latest, macos-latest, windows-latest] × ['3.11', '3.12', '3.13'](line 60-62), but the lint job pins Python 3.11 only (line 22). New deprecation warnings or syntax changes that fire on 3.12 or 3.13 only would slip past lint.See
CODEBASE_CRITIQUE.md§8 (Dependencies and tooling, "Finding (Medium) — CIlintjob pins Python 3.11 only;testmatrix is 3.11/3.12/3.13").Suggested approach
Either:
Add a Python-version matrix to the lint job:
Or move
ruff check/mypy/pip-audit/sphinx-build/pymarkdowninto the existing test matrix. This bundles three jobs into one (cheaper), but loses the ability to run lint in parallel with tests.Approach #1 keeps the existing structure and adds two extra lint runs (~30 s each). Approach #2 simplifies the workflow but couples lint to test cell health.
Recommended
Approach #1 — keeps lint a fast, independent gate while still covering every supported Python version. The cost is small and the failure modes are easier to diagnose (a lint failure on 3.13 doesn't block the 3.11 test cell from running).
Acceptance criteria
pip-audit .runs at least once per CI run (not once per cell).Related
CODEBASE_CRITIQUE.md§8 — original finding.