Python 3.15.0 正式登陆 actions/python-versions，CI 测试矩阵可直接启用

GitHub Actions 的 actions/python-versions 仓库近日合并了一个提交，正式将稳定版 Python 3.15.0 纳入支持列表。对于依赖 GitHub Actions 进行多版本测试的 Python 项目来说，这意味着只需在测试矩阵中加入 "3.15"，即可在 CI 流水线中对最新 Python 版本运行测试。

一个不起眼的仓库，牵动大量项目的 CI 神经

actions/python-versions 是 GitHub Actions 生态中负责管理 Python 版本安装的基础设施仓库。当开发者在 workflow 中使用 actions/setup-python 并指定版本号时，背后实际拉取的 Python 构建清单就来自这个仓库。因此，新 Python 版本能否在 CI 中顺畅使用，取决于该仓库是否已收录对应的版本条目。

这次提交的内容本身并不复杂，但其影响范围颇为广泛。任何在测试矩阵中采用「最新版本」策略的项目，都可以将 3.15 加入组合，从而提前验证代码兼容性。

为什么版本收录总是「慢半拍」

Python 新版本发布后，actions/python-versions 需要经过构建、验证、上传产物等一系列流程，才能将对应版本正式纳入。这一时间差通常为数天，对于跟踪前沿版本的开发者来说，等待过程颇为煎熬。

actions/setup-python 是 GitHub 官方提供的 Action，用于在 workflow 中安装并切换指定版本的 Python 解释器。它本身并不编译 Python，而是根据开发者传入的版本号（如 "3.15"）去 actions/python-versions 仓库查找对应的预编译产物清单，再从 GitHub Releases 下载对应平台的二进制包完成安装。这种设计将「版本管理」与「安装动作」分离：前者由专职仓库集中维护各平台、各架构的构建产物，后者只需做清单查询与解压配置。因此，actions/python-versions 收录新版本的速度，直接决定了使用 setup-python 的项目能否在 CI 中顺利切换到该版本。

Python 官方发布的源代码需要经过平台特定的构建过程才能变成 CI 可直接使用的二进制，而不同架构（x86_64、arm64）和操作系统（Ubuntu、macOS、Windows）对构建环境的依赖各不相同。actions/python-versions 的维护者需要为每个目标平台分别编译、打标签、生成校验和（如 SHA256），再上传到对应的 Release 资产中，并更新清单文件。这一链条中任何一环出现构建失败或依赖缺失，都会导致部分平台延迟发布。此外，稳定版与预发布版（如 alpha、beta、rc）通常分开处理，只有正式稳定版才会被纳入默认可用列表，这也解释了为何收录总比官方发布「慢半拍」。

开发者的「土办法」：让 ChatGPT 每小时轮询一次

这则消息的趣味之处在于发现者的做法。Simon Willison 在博客中提到，自己等了好几天，甚至给 ChatGPT 下了一条指令：克隆 actions/python-versions 仓库，每小时执行一次 git pull，直到稳定版 3.15 被加入，然后通知他。

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

这种做法把 LLM 当成一个持续运行的监控代理来使用，绕开了传统 CI 通知或 RSS 订阅的路径。它展示了一种朴素但有效的自动化思路：用自然语言描述轮询逻辑，让模型代替人盯着仓库变化。当然，这种方式更适合个人临时需求，生产环境仍应依赖 webhook 或定时任务等更可靠的机制。

从「盯仓库」到「CI 自动感知」

对于团队项目而言，更稳妥的做法是将版本更新纳入既有的依赖管理流程，例如通过 Renovate 或 Dependabot 监控 Python 版本变更，或定期检查 actions/python-versions 的 release 记录。

这里的「LLM 作为监控代理」本质上仍未跳出传统轮询模型，只是把编写轮询脚本的工作交给了自然语言指令。ChatGPT 在具备代码执行或工具调用能力时，可以实际运行 git clone、git pull 并在检测到目标提交后触发通知，但这类会话通常有超时限制，并不适合长期后台运行。更可靠的做法仍是使用 GitHub 自带的 Watch 功能、仓库的 RSS/Atom feed，或通过 GitHub API 的 releases 端点配合 cron 定时任务做差异比对。Simon Willison 的做法更多是一种个人化的临时方案，其价值在于展示「用自然语言描述自动化逻辑」的可行性，而非推荐用于生产监控。

如何在 GitHub Actions 中使用 Python 3.15

实际配置非常直接。在 workflow 的矩阵策略中加入 "3.15" 即可：

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

需要注意的是，部分第三方依赖可能尚未针对 3.15 发布预编译 wheel，CI 中可能会触发源码构建，导致运行时间变长。建议先在非阻塞的 job 中试用，观察稳定性后再纳入必过检查。

提前测试的价值

把新 Python 版本尽早纳入测试矩阵，可以在正式迁移前暴露语法弃用、C 扩展兼容性等问题。对于维护开源库的开发者来说，这几乎是低成本高回报的举措。

Python 3.15.0 进入 actions/python-versions 只是版本适配链条中的一小步，但它标志着新版本正式进入可被 CI 消费的阶段。接下来值得关注的，是主流依赖库何时跟进发布兼容的 wheel，以及各类工具链对 3.15 的支持进度。

在 Python 生态中，C 扩展模块（如 NumPy、Pillow、cryptography 等）依赖 CPython 的稳定 ABI 来发布预编译 wheel；当新 Python 版本刚发布时，这些库往往还没有对应的 wheel，pip 只能回退到从源码编译，从而显著延长 CI 时长。开发者可以借助 pip install --only-binary=:all: 在测试中强制要求二进制包，以便快速识别哪些依赖尚未跟上；也可以在矩阵中对该版本设置 continue-on-error: true，让它以「非阻塞」方式运行，等生态成熟后再转为必过检查。这样既提前获得了兼容性信号，又不会因依赖缺失而阻塞主分支的合并流程。