PyPy 的发布流程

发布策略

我们尝试每年发布几次稳定版本。这些版本发布在名为 release-pypy3.5-v2.x 或 release-pypy3.5-v4.x 的分支上，每个版本都带有标签，例如 release-pypy3.5-v4.0.1。

发布版本号应该递增。微版本递增意味着没有进行需要重新构建 c-extension 轮子的更改，因为轮子只标记了主版本号和次版本号。通常不清楚什么构成“主”版本和“次”版本，发布经理可以做出决定。

发布后，不可避免地会出现 bug 修复。修复 bug 的提交者的责任是确保此修复在发布分支上，以便我们可以创建带标签的 bug 修复版本，希望这比稳定版本发布更频繁。

如何创建 PyPy 版本

作为元规则，在跟踪器中为这里的内容设置问题可能有助于避免遗漏。一组 todo 文件也可以工作。

检查并优先考虑所有发布问题，如有必要推迟一些问题，也根据需要创建新问题。重要的是要使文档保持最新状态！

发布步骤

创建发布分支

这仅在您要进行新的主版本时才需要；如果不是，您可能可以使用现有的发布分支。

我们希望能够自由地将默认分支合并到分支中，反之亦然；因此，我们需要进行复杂的舞蹈以避免在合并时修补版本号

$ hg up -r default
$ # edit the version to e.g. 7.0.0-final
$ hg ci
$ hg branch release-pypy2.7-v7.x && hg ci
$ hg up -r default
$ # edit the version to 7.1.0-alpha0
$ hg ci
$ hg up -r release-pypy2.7-v7.x
$ hg merge default
$ # edit the version to AGAIN 7.0.0-final
$ hg ci

然后，我们需要对 3.x 分支执行相同的操作

$ hg up -r py3.5
$ hg merge default # this brings the version fo 7.1.0-alpha0
$ hg branch release-pypy3.5-v7.x
$ # edit the version to 7.0.0-final
$ hg ci
$ hg up -r py3.5
$ hg merge release-pypy3.5-v7.x
$ # edit the version to 7.1.0-alpha0
$ hg ci

要更改版本，您需要编辑三个文件

  • module/sys/version.py: PYPY_VERSION 应该类似于 (7, 3, 10, "final", 0) 或 (7, 3, 9, "candidate", 2) 用于 rc2。
  • module/cpyext/include/patchlevel.h: PYPY_VERSION 应该类似于“7.3.10”用于最终版本或“7.3.10-candidate3”用于 rc3。
  • doc/conf.py

向仓库添加标签。提交后永远不要更改标签：这会破坏下游打包工作流程。

  • 确保版本检查通过（它们确保 version.py 和 patchlevel.h 一致）
  • 确保标签与 version.py/patchlevel.h 中的版本匹配。虽然 repackage.sh 脚本会检查这一点，但一旦标签公开，就为时已晚。

其他步骤

  • 确保 RPython 在 buildbot 上构建通过，没有失败。

  • 可能需要在 module/imp/importing 中增加 SOABI 版本号。这会带来很多影响，所以要确保 PyPy 社区同意更改。Wheels 会在名称中使用主版本号和次版本号，因此如果对 cpyext 有不兼容的更改，则需要增加版本号。

  • 确保 binary-testing CI 是干净的，或者理解失败的原因。

  • 更新和编写文档

    • 更新 pypy/doc/contributor.rst（可能还有 LICENSE）pypy/doc/tool/makecontributor.py 生成贡献者列表
    • 编写发布公告 pypy/doc/release-VERSION.rst 发布公告应包含指向下载页面的直接链接
    • 将新文件添加到 pypy/doc/index-of-release-notes.rst

  • 构建并上传发布 tar 包

    • 转到 pypy/tool/release 并运行 force-builds.py <release branch> 应该构建以下 JIT 二进制文件，但是我们需要更多 buildbot windows-64、linux-32、linux-64、macos_x86_64、macos_arm64、aarch64、s390x

    • 等待构建完成，确保没有失败

    • 发送邮件列表消息，要求人们在上传到 pypy.org 之前进行测试，以防止多次上传

    • 在 pypy/jitviewer 存储库中添加一个与 pypy 版本对应的标签，以便在后续步骤中生成源代码 tar 包

    • 下载构建版本，重新打包二进制文件。标记发布候选版本（将其标记为候选版本很重要，因为通常至少需要两次尝试才能完成此过程），并从 buildbot 下载和重新打包源代码。你可能会发现使用 repackage.sh 脚本（位于 pypy/tool/release 中）来执行此操作很方便。

      还重新打包并上传源代码“ -src.tar.bz2”

    • 将二进制文件上传到 https://buildbot.pypy.org/mirror。将文件添加到 versions.json（位于 pypy/tools/release 中），上传它，然后运行该目录中的 check_versions.py 文件。此文件由各种下游工具（如“github actions”）使用来查找有效的 pypy 下载。https://downloads.python.org/pypy/ 同步需要一个小时。请注意“latest_pypy”属性：它是针对每个 Python 版本的。因此，如果新版本覆盖了当前的 latest_pypy（例如，两者都是 2.7.18），则必须找到旧版本并将它的“lastest_pypy”设置为“false”，否则 check_versions.py（以及各种工具）将失败。

  • 发送邮件列表消息，要求进行最后一分钟的评论和测试

  • 发布！

    • 使用 repackage.sh 脚本或手动生成的校验和哈希值以及下载页面更新 pypy.org
    • 在 pypy.org 上发布公告
    • 将公告发送到 twitter.com、pypy-dev、python-list、python-announce、python-dev …

  • 如果一切正常，请记录发布的版本并建议流行的工具更新以支持它。Github actions 将获取 versions.json。