Python 3.15 RC2发布：兼容性测试与CI配置实战指南

Python 3.15 的最终发布候选版本（Release Candidate 2）已经正式登场，预计将于今年 10 月正式发布。作为 Python 3.14 和 3.15 的发布经理，Hugo van Kemenade 宣布进入 RC 阶段后，代码库将进入冻结状态。这对整个 Python 生态系统的第三方库维护者和普通开发者来说，都是一个重要的信号。

RC 阶段对 Python 开发者意味着什么

发布候选版（Release Candidate）是软件在正式发布前的最后一道关卡。在 Python 的发布流程中，一个新版本通常会经历 alpha（功能探索期，允许添加新特性）、beta（功能冻结期，只允许修复 Bug 和完善文档）、RC（发布候选期，仅允许关键 Bug 修复）三个预发布阶段，最终才进入正式发布。这套流程遵循 PEP 101（Python 发布流程指南）和各版本对应的 PEP 发布计划，确保每个版本在面世前经过充分的社区验证。RC2 意味着这是第二个发布候选版本，说明 RC1 中发现了需要修复的问题。如果 RC2 在一定观察期内没有暴露新的严重缺陷，它将几乎原样成为正式版。

进入这个阶段后，规则变得非常严格：只有经过审查、且属于明确 Bug 修复的代码变更才被允许合并进主线。换句话说，Python 3.15 的核心功能已经全部定型，不会再有新特性加入，官方现在的重心完全放在稳定性和缺陷修复上。

发布经理在公告中特别强烈建议第三方 Python 项目的维护者在这个阶段就着手为 3.15 做准备工作，并在 PyPI 上发布针对 Python 3.15 的二进制 wheel 包。这里需要解释一下 wheel 包的重要性：Wheel 是 Python 的标准二进制分发格式（由 PEP 427 定义），文件扩展名为 .whl。与源码分发（sdist）不同，wheel 包是预编译的，用户安装时无需在本地执行编译步骤。这对于包含 C/C++/Rust 扩展模块的库（如 NumPy、scikit-learn、cryptography）尤为重要——这些库的源码编译不仅耗时，还要求用户本地安装相应的编译器和开发依赖。wheel 包的文件名中编码了目标 Python 版本、ABI 标签和操作系统平台信息（例如 numpy-1.26.0-cp315-cp315-manylinux_2_17_x86_64.whl），因此当新版本 Python 发布时，维护者需要针对新的 CPython ABI 重新编译并上传对应的 wheel。

尽早发布 wheel 有两个好处：

• 让自己的项目在 3.15.0 正式发布时就能开箱即用
• 帮助其他依赖你项目的库提前完成各自的兼容性测试

一个关键的技术承诺是：任何针对 Python 3.15.0 RC 版本编译的二进制 wheel，都将与未来所有的 Python 3.15.x 版本兼容。这一承诺基于 Python 的版本内 ABI 兼容性保证——同一个主要版本系列（如 3.15.0 到 3.15.x）内，CPython 的 C ABI 保持稳定不变。这意味着维护者现在投入的构建工作不会白费，无需在正式版发布后重新编译。

关于发布经理这一角色

值得一提的是，发布经理（Release Manager）是 CPython 项目中一个关键的社区治理角色。每个 Python 主要版本系列会指定一位发布经理，负责整个版本从首个 alpha 到最终安全更新的完整生命周期（通常长达五年）。发布经理的职责包括：决定版本发布的具体时间表、审批进入代码冻结阶段后的代码变更、协调基础设施团队完成构建和分发、撰写发布公告等。Hugo van Kemenade 同时担任 Python 3.14 和 3.15 两个版本的发布经理，这在 CPython 历史上并不罕见。发布经理由 Python 指导委员会（Steering Council）任命，通常是长期活跃的核心开发者。

为什么要在 RC 阶段测试 Python 新版本

知名开发者 Simon Willison 分享了一个颇具说服力的亲身教训。早在 2021 年，他曾通过在 Python 3.10 上运行自己的测试套件发现了一个 Bug——但问题在于，他并没有在 RC 阶段进行测试，等到发现时，这个 Bug 已经随着正式版一起发布了。

从那以后，我就一直非常密切地关注这些 RC 版本。

这个故事道出了 RC 测试的核心价值：在 Bug 随正式版扩散之前，社区还有机会将其拦截并修复。如果每个项目维护者都能在 RC 阶段跑一遍自己的测试套件，Python 正式版的质量将得到显著保障。这是开源协作模式下"众人拾柴"的典型体现——每个人的测试都是对整个生态系统的贡献。

实际上，CPython 的测试体系虽然庞大（包含数万个测试用例），但它不可能覆盖所有第三方库的使用场景。许多 Bug 只会在特定的 API 调用模式、特定的数据规模或特定的操作系统环境下被触发。第三方项目的测试套件恰好弥补了这一空白——它们代表了 Python 在真实生产场景中的实际使用方式，是 CPython 官方测试的重要补充。

GitHub Actions 自动化测试 Python 3.15 的配置方法

虽然截至公告发布时，这个新的 RC 版本尚未在 GitHub Actions 上直接可用（开发者需要留意 actions/python-versions 的发布动态），但可以通过配置测试矩阵来实现自动化预发布测试。

GitHub Actions 是 GitHub 提供的持续集成/持续部署（CI/CD）平台，允许开发者通过 YAML 配置文件定义自动化工作流。这里使用的"测试矩阵"（matrix strategy）是 CI 领域的一个核心概念：它允许用单一配置同时在多个环境维度（Python 版本、操作系统、依赖版本等）的笛卡尔积上并行运行测试。actions/setup-python 是 GitHub 官方维护的 Action，负责在 CI 运行器上安装指定版本的 Python。它依赖 actions/python-versions 仓库中预编译的 Python 发行版——这就是为什么新的 RC 版本需要等待该仓库更新后才能在 CI 中使用。

只需在 CI 配置中添加如下内容：

strategy:
  matrix:
    python-version: ["3.14", "3.15"]

steps:
  - uses: actions/setup-python@v7
    with:
      python-version: ${{ matrix.python-version }}
      allow-prereleases: true
      check-latest: true

这段配置的精妙之处在于两个标志位的组合使用：

• allow-prereleases: true：允许 setup-python 拉取预发布版本，测试会自动针对当前最新的 RC 版本运行。
• check-latest: true：确保始终使用最新可用版本。当 RC2 上线后，测试会自动切换到 RC2；等到正式版发布，又会平滑过渡到稳定版。

这种"设置一次，自动跟进"的机制，极大降低了持续测试预发布版本的维护成本。开发者无需手动追踪每一次 RC 迭代，CI 流水线会自动帮你保持在最新前沿。对于 Python 生态中的开源项目来说，在 CI 矩阵中覆盖预发布版本已经成为一种最佳实践，许多知名项目（如 Django、Flask、requests）都采用了类似的配置策略。

Python 3.15 生态兼容性的真实进展

Simon Willison 公开了自己旗下几个项目在 Python 3.15 上的实测结果，为观察生态兼容性提供了一个真实的切面：

项目	测试状态	备注
Datasette	✅ 通过	—
sqlite-utils	✅ 通过	—
LLM	⚠️ 受阻	scikit-learn 尚未提供 Python 3.15 wheel 包

这个案例恰好揭示了 Python 生态兼容性的链式依赖特点：一个项目能否顺利支持新版本，往往不只取决于自身代码，还受制于其依赖库的适配进度。像 scikit-learn 这类包含大量 C/C++ 扩展、需要针对特定 Python 版本编译二进制 wheel 的库，通常需要更长的适配周期。

深入来看，链式依赖问题是每次 Python 大版本升级时最突出的工程挑战之一。现代 Python 项目通常拥有庞大的依赖树——一个中等规模的 Web 应用可能直接或间接依赖数十甚至上百个第三方包。当 Python 发布新版本时，适配必须从依赖链的最底层开始逐层向上推进。以 scikit-learn 为例，它自身依赖 NumPy、SciPy 等底层科学计算库，这些库又包含大量通过 Cython 编译或直接用 C/Fortran 编写的扩展模块。每一层都需要确认与新版 CPython 的 C API/ABI 兼容性，必要时修改代码并重新编译。如果 Python 3.15 中引入了 C API 层面的变更（如废弃某些函数、修改数据结构布局），影响面会沿依赖链逐级放大。这也是为什么 CPython 核心团队近年来持续推进"限制 C API"（Limited C API / Stable ABI，PEP 384）和 HPy 等项目，旨在减少扩展模块与 CPython 内部实现的耦合度，从根本上缓解每次版本升级带来的适配压力。

这也从侧面解释了为什么发布经理如此强调让维护者尽早发布 3.15 wheel——处于依赖链上游的基础库越早完成适配，下游项目的整体迁移就越顺畅。

不同角色的开发者该怎么做

Python 3.15 RC2 的发布，标志着新版本已进入最后的稳定化冲刺阶段。对于不同角色的开发者，此刻都有明确的行动方向：

库维护者：立即在 CI 中加入 Python 3.15 测试矩阵，尽早在 PyPI 发布 wheel 包，抢占依赖链适配的先机。

应用开发者：跑一遍测试套件验证兼容性，若发现 Bug 尽快向 CPython 官方反馈——这可能是修复它的最后窗口期。值得注意的是，CPython 使用 GitHub Issues 作为 Bug 追踪系统（仓库地址为 github.com/python/cpython），提交 Bug 报告时应尽量附上最小可复现示例（Minimal Reproducible Example），这将大幅提升核心开发者定位和修复问题的效率。

普通用户：暂时无需升级，但可以关注自己常用工具链的 3.15 适配状态，为 10 月的正式版发布做好规划。可以通过查看各项目的 CI 状态徽章或 PyPI 上的 Python 版本分类器（Trove Classifiers）来了解适配进展。

距离 Python 3.15.0 正式发布只剩下不到两个月的时间。这段窗口期，正是整个社区共同打磨新版本质量的黄金时刻。

核心要点