Python 3.15.0 Officially Lands in actions/python-versions, Ready to Enable in CI Test Matrices

The actions/python-versions repository for GitHub Actions recently merged a commit that officially adds stable Python 3.15.0 to its supported list. For Python projects relying on GitHub Actions for multi-version testing, this means that simply adding "3.15" to the test matrix lets you run tests against the latest Python version in your CI pipeline.

An unassuming repository that drives CI for a huge number of projects

actions/python-versions is the infrastructure repository in the GitHub Actions ecosystem responsible for managing Python version installations. When developers use actions/setup-python in a workflow and specify a version number, the Python build manifest actually fetched behind the scenes comes from this repository. Therefore, whether a new Python version can be used smoothly in CI depends on whether the corresponding version entry has been added to this repository.

The content of this commit itself isn't complicated, but its reach is quite broad. Any project that adopts a "latest version" strategy in its test matrix can now add 3.15 to the mix and validate code compatibility ahead of time.

Why version inclusion is always "a beat behind"

After a new Python version is released, actions/python-versions needs to go through building, verification, uploading artifacts, and a series of other steps before the corresponding version is officially included. This time lag is usually several days, and for developers tracking cutting-edge versions, the wait can be quite painful.

actions/setup-python is the official GitHub-provided Action for installing and switching to a specified version of the Python interpreter in a workflow. It does not compile Python itself; instead, based on the version number passed in by the developer (e.g., "3.15"), it looks up the corresponding pre-built artifact manifest in the actions/python-versions repository, then downloads the binary package for the target platform from GitHub Releases to complete the installation. This design separates "version management" from "installation action": the former is centrally maintained by a dedicated repository for build artifacts across platforms and architectures, while the latter only needs to do manifest lookup, extraction, and configuration. As a result, the speed at which actions/python-versions includes new versions directly determines whether projects using setup-python can switch to that version smoothly in CI.

The official Python source code needs to go through platform-specific build processes before it becomes a binary that CI can use directly, and different architectures (x86_64, arm64) and operating systems (Ubuntu, macOS, Windows) have different dependencies for their build environments. The maintainers of actions/python-versions need to compile, tag, and generate checksums (such as SHA256) separately for each target platform, then upload them to the corresponding Release assets and update the manifest file. Any build failure or missing dependency in this chain will delay release for some platforms. In addition, stable and pre-release versions (such as alpha, beta, rc) are usually handled separately, and only official stable versions are included in the default available list, which also explains why inclusion is always "a beat behind" the official release.

A developer's "hacky" approach: have ChatGPT poll once an hour

The amusing part of this news is how the discoverer went about it. In his blog, Simon Willison mentioned that he had waited several days and even gave ChatGPT an instruction: clone the actions/python-versions repository, run git pull once an hour until stable 3.15 was added, then tell him.

Clone https://github.com/actions/python-versions and git pull once an hour until they add the stable 3.15 - then tell me about it

This approach uses the LLM as a continuously running monitoring agent, bypassing the traditional path of CI notifications or RSS subscriptions. It demonstrates a simple but effective automation idea: describe the polling logic in natural language and let the model watch repository changes on your behalf. Of course, this method is more suited to temporary personal needs; in production, you should still rely on more reliable mechanisms such as webhooks or scheduled jobs.

From "watching the repository" to "CI auto-awareness"

For team projects, a more robust approach is to incorporate version updates into existing dependency management processes, such as monitoring Python version changes through Renovate or Dependabot, or periodically checking the release records of actions/python-versions.

The idea of an "LLM as a monitoring agent" here still essentially stays within the traditional polling model; it just shifts the work of writing polling scripts to natural language instructions. When ChatGPT has code execution or tool calling capabilities, it can actually run git clone, git pull, and trigger a notification after detecting the target commit, but such sessions usually have timeout limits and are not suitable for long-term background operation. A more reliable approach is still to use GitHub's built-in Watch feature, the repository's RSS/Atom feed, or the GitHub API releases endpoint together with a cron job for difference comparison. Simon Willison's method is more of a personalized temporary solution; its value lies in demonstrating the feasibility of "describing automation logic in natural language," not in recommending it for production monitoring.

How to use Python 3.15 in GitHub Actions

The actual configuration is very straightforward. Just add "3.15" to the workflow's matrix strategy:

strategy:
  matrix:
    python-version: ["3.12", "3.13", "3.14", "3.15"]
steps:
  - uses: actions/setup-python@v5
    with:
      python-version: ${{ matrix.python-version }}

Note that some third-party dependencies may not yet have published pre-built wheels for 3.15, which may trigger source builds in CI and increase runtime. It is recommended to first try it in a non-blocking job and only add it to required checks after observing stability.

The value of early testing

Including new Python versions in the test matrix as early as possible can expose issues such as syntax deprecations and C extension compatibility before a formal migration. For developers maintaining open-source libraries, this is almost a low-cost, high-return move.

Python 3.15.0 entering actions/python-versions is only a small step in the version adaptation chain, but it marks the point at which the new version officially becomes consumable by CI. What is worth watching next is when mainstream dependency libraries will follow up with compatible wheels, and how quickly various toolchains will support 3.15.

In the Python ecosystem, C extension modules (such as NumPy, Pillow, cryptography, etc.) rely on CPython's stable ABI to publish pre-built wheels; when a new Python version is first released, these libraries often do not yet have corresponding wheels, so pip can only fall back to compiling from source, significantly lengthening CI time. Developers can use pip install --only-binary=:all: in tests to force binary packages, so they can quickly identify which dependencies have not caught up; they can also set continue-on-error: true for that version in the matrix, letting it run in a "non-blocking" way, and then switch it to a required check once the ecosystem matures. This way, you gain compatibility signals early without blocking the main branch's merge process due to missing dependencies.

One-line Summary

GitHub Actions has added Python 3.15.0, so CI matrices can directly test the latest version.

Paragraph Summary

The actions/python-versions repository for GitHub Actions has merged Python 3.15.0. As the underlying manifest source used by setup-python to install Python, this means developers only need to add "3.15" to their test matrix to validate compatibility with the latest version in CI. The article explains the repository's pivotal role and how including a new version requires building, verification, uploading artifacts, and other steps, so it is always several days behind the official release. The amusing part is that Simon Willison used ChatGPT to poll the repository with git pull once an hour, demonstrating a simple use of an LLM as a monitoring agent. The article ends with a configuration example and a reminder that some third-party dependencies may lack pre-built wheels, causing CI to trigger source builds and slow down, so it is recommended to try it first in a non-blocking way.