From 6f992f863f784bece015fc9af2d02cc31d03d8e5 Mon Sep 17 00:00:00 2001 From: dzerik Date: Sun, 9 Aug 2026 13:16:24 +0300 Subject: [PATCH] ci: test the Python versions the release already builds wheels for `release.yml` builds cp313 and cp314 wheels and runs the release test matrix on 3.13 and 3.14 (#157), but `ci.yml` has tested 3.10 to 3.12 since the first commit. So the two newest interpreters the project ships are exercised only while a release is being cut, which is the worst moment to learn that one of them is broken: the tag is already pushed, and whoever is cutting the release has to choose between holding it and shipping a wheel nobody ran the tests against. Nothing here is hypothetical about the SDK's exposure to an interpreter change. It drives libsandlock_ffi through ctypes, hands the library Python-owned buffers and callbacks, and frees what the C ABI hands back from `__del__` and from context managers. Those are the parts of the language that move between versions. Verified before proposing it: on this host the full Python suite behaves identically on 3.12, 3.13 and 3.14, same pass count and the same set of failing names byte for byte, so this widens coverage without widening the red. The failures in that run are this host's own (no privileged sandbox); the point is that the three interpreters agree. Cost is four extra jobs, since the matrix crosses two runners. If that is more than it is worth, an `exclude` that keeps 3.13 and 3.14 on ubuntu-latest alone would still catch an interpreter regression while adding two. --- .github/workflows/ci.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index f27d9944..e17a8296 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -128,7 +128,7 @@ jobs: fail-fast: false matrix: runner: [ubuntu-latest, ubuntu-24.04-arm] - python-version: ["3.10", "3.11", "3.12"] + python-version: ["3.10", "3.11", "3.12", "3.13", "3.14"] steps: - uses: actions/checkout@v4