Python 3.15.0 lands in GitHub Actions: time to update your test matrix

A commit with a stable build of Python 3.15.0 has appeared in the actions/python-versions repository. It is a narrow piece of news, but for thousands of GitHub projects it is a signal: you can add "3.15" to your test matrix and check your code on the new interpreter without building it yourself. Developer Simon Willison had been waiting for this moment for several days. He even asked ChatGPT to clone the repository, run git pull every hour, and report when stable 3.15 finally showed up.

Why the

Python release and CI availability are separated in time

When a new version comes out on python.org, GitHub Actions does not get it instantly. The setup-python action takes prebuilt interpreter builds from a manifest in the actions/python-versions repository. Until that manifest has an entry for 3.15.0, `python-version: "3.15"` either looks only at prereleases or finds no matching version. The maintainers have to build distributions for Linux, macOS, and Windows, run checks, and commit the update.

This is the step Willison was waiting for. The release was already out and the page on python.org existed, but CI still could not use it. For library authors, this gap is inconvenient: users install the new Python in the first few days, and it is better to catch a compatibility bug before they do.

How ChatGPT ended up as a repository watchman

Willison's prompt reads almost like a cron job written in natural language: clone https://github.com/actions/python-versions, run git pull every hour until stable 3.15 is added, and then report back. He published a link to the conversation. It is an everyday example of an agentic scenario: the model gets access to an environment with git, repeats an action on a schedule, and comes back with a result on its own once the condition is met.

The task is small but telling. Such things used to be handled with release subscriptions, RSS, or a script on a server. Now it is enough to describe the condition in words. The downside is just as obvious: how reliable this kind of watchman is depends on how exactly the chat product plans and runs repeated checks. A GitHub notification subscription or your own scheduled workflow gives a more predictable result. Willison's post does not report the outcome of the check, so there is nothing to judge the approach's effectiveness by.

What you need to know about setting it up

• Specify the version as a string: `"3.15"`. Without quotes, YAML may read the value as a float, and `3.10` becomes `3.1`. This trap has been known for a long time.
• Source of the builds: the manifest in actions/python-versions, which setup-python uses.
• Release page: python.org/downloads/release/python-3150.
• Tags on the post: GitHub, Python, GitHub Actions, ChatGPT.

In practice: what to do today

If you maintain a Python library or service, add `"3.15"` to your matrix, for example `python-version: ["3.13", "3.14", "3.15"]`. It is better to mark the first run as non-blocking via `continue-on-error`. That way, broken dependencies with native extensions will not stop the main pipeline. Wheels for the new version do not appear right away for popular packages, and the first red builds are often explained by exactly this, not by your code.

It is also worth reviewing the deprecation warnings that Python issued on previous versions. They are easier to fix in advance, before the old API is removed. If you have nightly builds or checks on Docker images, add 3.15 there too.

One last point: if you are waiting for an event in someone else's repository, you do not have to ask a chatbot to do it. A release subscription or a simple scheduled workflow is more reliable, and a chatbot makes sense when the condition is hard to describe formally.