Following system colour scheme - Python 增强提案 Selected dark colour scheme - Python 增强提案 Selected light colour scheme - Python 增强提案

Python 增强提案

PEP 101 – Python 发布 101

作者:
Barry Warsaw <barry at python.org>, Guido van Rossum <guido at python.org>
状态:
活跃
类型:
信息性
创建日期:
2001年8月22日
发布历史:

取代:
102
目录

摘要

进行 Python 发布是一个既令人兴奋又疯狂的过程。你听说过“放牧猫”这种说法吗？想象一下，你还要给那些咕噜作响的小家伙套上鞍，然后骑着它们进城，其中一些伙伴还牢牢地附在你的赤裸的背上，爪子锋利如新。你提醒自己，至少它们很可爱。

实际上，不，这有点夸张 😉 多年来，Python 的发布过程一直在稳步改进，现在，在我们出色社区的帮助下，它真的不那么困难了。本 PEP 试图在一个地方收集进行 Python 发布所需的所有步骤。大多数步骤现在都已自动化或由自动化引导，因此不再需要手动遵循此列表。

你需要的东西

作为发布经理，你需要访问许多资源。下面是一个希望能完整的列表。

  • GPG 密钥。

    Python 3.14 之前的版本通过 GPG 进行数字签名；对于这些版本，你需要一个密钥，希望它能与至少一个其他发布经理在“信任网络”中。

    注意

    对于 Python 3.14 及更高版本，本 PEP 中的 GPG 说明可以忽略。详见 PEP 761。

  • 一堆软件
    • 检出 python/release-tools 仓库。它包含一个 requirements.txt 文件，你需要先从中安装依赖项。之后，你可以启动仓库中的脚本，本 PEP 稍后会介绍。
    • blurb，Misc/NEWS 管理工具。你可以通过 pip 安装。
  • 访问用于上传文件的服务器
    • downloads.nyc1.psf.io，托管下载文件的服务器；以及
    • docs.nyc1.psf.io，托管文档的服务器。
  • python/cpython 的管理员访问权限。
  • www.python.org 上的管理员账户，包括一个“API 密钥”。
  • python/peps 仓库的写入权限。

    如果你正在阅读此内容，你可能已经拥有此权限——任何发布经理的首要任务都是起草发布时间表。但如果你刚刚注册……傻瓜！我的意思是，呃，恭喜！

  • 发布到 blog.python.org 的权限，这是一个由 Blogger 托管的博客。此博客的 RSS 提要用于 www.python.org 上的“Python 新闻”部分。
  • 订阅超级秘密发布经理邮件列表，其名称可能是也可能不是 python-cabal。就此问题联系 Barry。
  • 一个 @python.org 电子邮件地址，你将用它来签署你的发布。向 postmaster@ 申请一个地址；你可以获得一个完整账户，或者一个重定向别名 + SMTP 凭据，以便从该地址发送对主要电子邮件提供商而言合法的电子邮件。
  • 被添加到 Python 安全响应团队。

发布类型

你需要进行几种类型的发布。这些包括

  • alpha
  • begin beta，也称为 beta 1，也称为 new branch
  • beta 2+
  • release candidate 1
  • release candidate 2+
  • final
  • new branch
  • begin bugfix mode
  • begin security-only mode
  • end-of-life

其中一些发布类型实际上涉及多个发布分支。特别是，**新分支 (new branch)** 是发布周期中新功能发布周期开始的时间点。在 CPython Git 仓库的当前组织下，*main* 分支始终是新功能的开发目标。在下一个功能版本的发布周期中的某个时间点，会进行一次 **新分支** 发布，为当前正在进行的功能版本 (3.n.0) 的稳定和后续维护创建一个新的独立分支，并且 *main* 分支被修改以构建一个新版本（最终将作为 3.n+1.0 发布）。尽管 **新分支** 发布步骤可以在发布周期的几个时间点发生，但目前的做法是在计划进行第一个 Beta 发布的版本的特性代码截止时进行。

在接下来的描述中，特定于发布类型的步骤将相应地标记，目前为 **新分支** 和 **最终**。

如何发布

以下是进行 Python 发布的步骤。有些步骤比其他步骤更模糊，因为自动化程度较低（例如，编写 NEWS 条目）。如果某个步骤通常由专家执行，则会给出该专家的角色。否则，假设该步骤由发布经理 (RM) 执行，即执行发布的指定人员。角色及其当前的专家是

注意

强烈建议发布经理在发布前一天联系专家。由于地球是圆的，每个人都生活在不同的时区，发布经理必须确保及时创建发布标签，以便专家能够构建二进制发布。

在所有专家更新其文件之前，你不应公开发布（通过更新网站和发送公告）。在极少数情况下，如果 Windows 或 Mac 的专家缺席，你可以添加一条消息“(平台) 二进制文件将很快提供”，然后继续。

我们在以下示例中使用以下约定。如果给出发布号，其形式为 3.X.YaN，例如 Python 3.13.0 alpha 3 为 3.13.0a3，其中“a”表示 alpha，“b”表示 beta，“rc”表示发布候选。

发布标签名为 v3.X.YaN。次要版本维护分支的名称为 3.X。

尽可能地，发布由 run_release.py 脚本自动化和引导，该脚本在单独的仓库中可用：python/release-tools。这有助于自动化以下许多步骤，并引导你执行一些手动步骤。

  • 登录 Discord 并加入 Python Core Devs 服务器。向 Thomas 或 Łukasz 索取邀请。

    你可能需要与世界各地的人协调。这个沟通渠道是我们安排会面的地方。

  • 检查是否有任何阻止发布的 bug。

    前往 https://github.com/python/cpython/issues 查找任何可能阻止此发布的开放 bug。你正在查看两个相关的标签

    release-blocker
    完全阻止发布。你不允许发布任何带有未解决的发布阻止 bug 的版本。
    deferred-blocker
    不阻止此发布，但会阻止未来的发布。你不允许发布带有任何未解决的延迟阻止 bug 的最终版本或候选版本。

    审查发布阻止程序，并将其解决、降级为延迟，或者停止发布并寻求社区协助。如果你正在进行最终发布或候选发布，请对任何未解决的延迟问题执行相同操作。

  • 检查稳定构建机器人。

    前往 https://buildbot.python.org/all/#/release_status

    查看你正在发布的版本的构建机器人。忽略任何离线的（或通知社区以便重新启动）。如果剩余的（大部分）是绿色的构建机器人，你就可以继续了。如果你有非离线的红色构建机器人，你可能需要暂停发布，直到它们被修复。审查问题并酌情判断，考虑到你正在进行的是 alpha、beta 还是最终发布。

  • 创建发布克隆。

    在 GitHub 上的 CPython 仓库的一个分支中，在其内部创建一个发布分支（从现在开始称为“发布克隆”）。你可以使用用于 CPython 开发的相同 GitHub 分支。使用 Python 开发人员指南 中推荐的标准设置，你的分支将被称为 origin，标准 CPython 仓库将被称为 upstream。你将使用你分支上的分支来执行发布工程工作，包括标记发布，你将使用它与H其他专家共享以制作二进制文件。

    对于 **最终** 或 **发布候选 2+** 版本，如果你要从上次发布候选以来合并的所有更改中挑选一部分更改用于下一个 rc 或最终版本，你应该从最近的发布候选标签（即 v3.8.0rc1）开始创建一个发布工程分支。然后，你将根据需要在发布工程分支中选择标准发布分支中的更改，然后照常进行。如果你要获取自上一个 rc 以来所有更改，则可以照常进行。

  • 确保你的发布克隆的当前分支是你想要发布的版本分支（git status）。
  • 运行 blurb release <version> 并指定版本号（例如 blurb release 3.4.7rc1）。这会将所有最近的新闻简报合并到一个文件中，并标明此发布的版本号。
  • 重新生成 Lib/pydoc-topics.py。

    仍在 Doc 目录中时，运行

    make pydoc-topics
cp build/pydoc-topics/topics.py ../Lib/pydoc_data/topics.py
  • 提交你对 pydoc_topics.py 的更改（以及你在文档中进行的任何修复）。
  • 考虑使用当前接受的标准版本运行 autoconf，以防 configure 或其他由 Autoconf 生成的文件上次提交时使用了更新或更旧的版本，并可能包含虚假或有害的差异。目前，Autoconf 2.71 是我们的事实标准。如果存在差异，请提交它们。
  • 确保 Doc/tools/extensions/pyspecific.py 中的 SOURCE_URI 指向 Git 仓库中正确的分支（main 或 3.X）。对于 **新分支** 发布，将文件中的分支从 main 更改为你要创建的新发布分支（3.X）。
  • 通过发布脚本提升版本号
    .../release-tools/release.py --bump 3.X.YaN

    提醒：X、Y 和 N 应该是整数。a 应该是 a、b 或 rc 中的一个（例如 3.4.3rc1）。对于 **最终** 发布，省略 aN（3.4.3）。对于新版本 Y 的首次发布，Y 应该是 0（3.6.0）。

    这会自动化更新各种发布号，但你需要手动修改一些文件。如果你的 $EDITOR 环境变量设置正确，release.py 将弹出编辑器窗口，其中包含你需要编辑的文件。

    审查 blurb 生成的 Misc/NEWS 文件，并根据需要进行编辑。

  • 确保所有更改都已提交。（release.py --bump 不会为你提交其更改。）
  • 对于 **最终** 主要版本，编辑 Doc/whatsnew/3.X.rst 的第一段，以包含实际发布日期；例如“Python 2.5 于 2003 年 8 月 1 日发布。” alpha 或 beta 版本无需编辑此内容。
  • 在此目录中执行 git status。

    你不应该看到任何文件，也就是说，你的工作目录中最好不要有任何未提交的更改。

  • 为 3.X.YaN 标记发布
    .../release-tools/release.py --tag 3.X.YaN

    这将执行一个带有 -s 选项的 git tag 命令，以便仓库中的发布标签用你的 GPG 密钥签名。当提示时，选择你用于签署发布 tarball 等的私钥。

  • 对于 **开始安全模式** 和 **生命周期结束** 版本，请检查这两个文件并相应地更新所有活动分支中的版本。
  • 将你的提交推送到 GitHub 分支中的远程发布分支
    # Do a dry run first.
git push --dry-run --tags origin
# Make sure you are pushing to your GitHub fork,
# *not* to the main python/cpython repo!
git push --tags origin
  • 在 python/release-tools 中，转到 build-release 工作流，选择“Run workflow”，然后输入你刚刚创建的标签的详细信息。这将执行以下步骤
    • 创建源 gzip 和 xz tarball。
    • 创建文档 tar 和 zip 文件。
    • 检查源 tarball，确保完全干净的原始构建通过回归测试。
    • 构建并测试 Android 二进制文件（如果是 Python 3.14 或更高版本）。

    生成的工件将附加到 GitHub 工作流的摘要页面。一旦源 tarball 可用，请下载并解压缩它，以确保一切正常，没有散乱的 .pyc 文件等。

    如果测试通过，那么你可以放心，tarball 是好的。如果某些测试失败，或者新解压的目录看起来有任何异常，你最好现在停止并找出问题所在。

  • 通知专家们可以开始构建二进制文件了。

Warning

**停止**：此时你必须收到其他专家的“绿灯”才能创建发布。不过，你可以在等待时做一些事情，所以继续阅读直到遇到下一个停止。

  • WE 使用 .azure-pipelines/windows-release/ 中的 Azure Pipelines 构建脚本生成并发布 Windows 文件，当前设置在 https://dev.azure.com/Python/cpython/_build?definitionId=21。

    构建过程分多个阶段运行，每个阶段的输出都作为可下载的工件提供。阶段包括

    • 编译所有变体的二进制文件（32 位、64 位、调试/发布），包括运行配置文件引导优化。
    • 编译包含 Python 文档的 HTML 帮助文件。
    • 使用 PSF 证书对所有二进制文件进行代码签名。
    • 为 python.org、nuget.org、可嵌入发行版和 Windows 应用商店创建软件包。
    • 对安装程序执行基本验证。
    • 将软件包上传到 python.org 和 nuget.org，清除下载缓存并运行测试下载。

    上传完成后，WE 从构建日志中复制生成的哈希值并将其通过电子邮件发送给 RM。Windows 应用商店软件包由 WE 手动上传到 https://partner.microsoft.com/dashboard/home。

  • ME 构建 Mac 安装包，并将其与 GPG 签名文件一起上传到 downloads.nyc1.psf.io。
  • scp 或 rsync 将所有由 build-release 工作流构建的文件，连同任何签名、SBOM 等，复制到你在 downloads.nyc1.psf.io 上的主目录。

    在等待文件上传完成时，你可以继续执行剩余的任务。你也可以在 Discord 和/或 discuss.python.org 上请人们下载文件，以便他们也可以在自己的平台上进行测试。

  • 现在你需要前往 downloads.nyc1.psf.io 并将所有文件移动到正确的位置。我们的策略是每个 Python 版本都有自己的目录，但每个目录包含该版本的所有发布。
    • 在 downloads.nyc1.psf.io 上，cd /srv/www.python.org/ftp/python/3.X.Y，如果需要则创建它。确保它归组 downloads 所有，并且组可写。
    • 将你上面上传到主目录的文件移动到发布目录中。Windows/Mac 二进制文件通常由专家自己放置。

      确保它们可被所有用户读取。它们也应该是组可写的，并且归组 downloads 所有。

    • 使用 gpg --verify 确保它们上传完整。
    • 如果这是 **最终** 版本或 rc 版本：将文档 zip 和 tarball 移动到 /srv/www.python.org/ftp/python/doc/3.X.Y[rcA]，如果需要则创建目录，并调整 .../doc 中的“current”符号链接指向该目录。请注意，如果你正在发布旧版本的维护版本，请不要更改 current 链接。
    • 如果这是 **最终** 版本或 rc 版本（即使是维护版本），请同时将 HTML 文档解压缩到 docs.nyc1.psf.io 上的 /srv/docs.python.org/release/3.X.Y[rcA]。确保文件属于 docs 组，并且组可写。
    • 让 DE 检查文档是否构建和运行正常。
    • 请注意，文档和下载都位于缓存 CDN 之后。如果你在通过网站下载文件后更改了档案，则需要像这样清除 CDN 中的陈旧数据
      curl -X PURGE https://pythonlang.cn/ftp/python/3.12.0/Python-3.12.0.tar.xz

      你应该始终清除目录列表的缓存，因为人们会使用它来浏览发布文件。

      curl -X PURGE https://pythonlang.cn/ftp/python/3.12.0/
  • 对于特别谨慎的人，请对发布进行一次完全干净的测试。这包括从 www.python.org 下载 tarball。

    确保 md5 校验和匹配。然后解压 tarball，并进行干净的 make test

    make distclean
./configure
make test

    以确保回归测试套件通过。否则，你肯定在某个地方搞砸了！

Warning

**停止** 并确认

  • 你是否收到了 WE 的绿灯？
  • 你是否收到了 ME 的绿灯？
  • 你是否收到了 DE 的绿灯？

如果亮绿灯，是时候将发布工程分支合并回主仓库了。

  • 为了将你的更改推送到 GitHub，你必须暂时禁用管理员的分支保护。前往 Settings | Branches 页面

    https://github.com/python/cpython/settings/branches

    “编辑”你正在发布的分支的设置。这将加载该分支的设置页面。取消选中“包括管理员”框，然后按底部的“保存更改”按钮。

  • 将你的发布克隆合并到主开发仓库中
    # Pristine copy of the upstream repo branch
git clone git@github.com:python/cpython.git merge
cd merge

# Checkout the correct branch:
# 1. For feature pre-releases up to and including a
#    **new branch** release, i.e. alphas and first beta
#   do a checkout of the main branch
git checkout main

# 2. Else, for all other releases, checkout the
#       appropriate release branch.
git checkout 3.X

# Fetch the newly created and signed tag from your clone repo
git fetch --tags git@github.com:your-github-id/cpython.git v3.X.YaN
# Merge the temporary release engineering branch back into
git merge --no-squash v3.X.YaN
git commit -m 'Merge release engineering branch'
  • 如果这是一个 **新分支** 发布，即第一个 Beta 版，现在创建新的发布分支
    git checkout -b 3.X

    执行设置新发布分支所需的任何步骤，包括

    • 在 README.rst 中，将所有对 main 的引用更改为新分支，特别是 GitHub 仓库 URL。
  • 对于 *所有* 发布，请使用发布脚本执行引导的发布后步骤
    .../release-tools/release.py --done 3.X.YaN
  • 对于 **最终** 或 **发布候选 2+** 版本，你可能需要进行一些合并后清理。检查顶层 README.rst 和 include/patchlevel.h 文件，确保它们现在反映了正在进行的开发的期望发布后值。补丁级别应为带 + 的发布标签。此外，如果你为本次发布将标准发布分支中的更改选择性地合并到发布工程分支中，那么你现在需要手动从 Misc/NEWS.d/next 目录中删除所有已选择性合并到你正在处理的发布中的 blurb 条目，因为该 blurb 条目现在已在合并到新发布的 x.y.z.rst 文件中。否则，该 blurb 条目将在 changelog.html 文件中出现两次，一次在 Python next 下，另一次在 x.y.z 下。
  • 审查并提交这些更改
    git commit -m 'Post release updates'
  • 如果这是一个 **新分支** 发布（例如，第一个 Beta 版），请更新 main 分支以开始后续功能版本的开发。完成后，main 分支将构建 Python X.Y+1。
    • 首先，将 main 设置为下一个版本，即 X.Y+1.a0
      git checkout main
.../release-tools/release.py --bump 3.9.0a0
    • 编辑 README.rst 中的所有版本引用
    • 编辑 Doc/tutorial/interpreter.rst（两处引用“[Pp]ython3x”，一处引用“Python 3.x”，还要使横幅中的日期保持一致）。
    • 编辑 Doc/tutorial/stdlib.rst 和 Doc/tutorial/stdlib2.rst，它们都各有一处引用“[Pp]ython3x”。
    • 添加一个新的 whatsnew/3.x.rst 文件（顶部附近有注释，顶级部分从上一个文件复制），并将其添加到 whatsnew/index.rst 中的 toctree。但请注意，由于初始的 blurb 中途更改从一个版本传播到另一个版本，因此以前版本的初始 whatsnew/3.x.rst 签入可能不正确！帮助打破这个循环：如有必要，进行以下更改
      -For full details, see the :source:`Misc/NEWS` file.
+For full details, see the :ref:`changelog <changelog>`.
    • 更新 configure.ac 中的版本号并重新运行 autoconf。
    • 确保 Doc/tools/extensions/pyspecific.py 中的 SOURCE_URI 指向 main。
    • 更新 Windows 构建的版本号，其中包含对 python38 的引用
      ls PC/pyconfig.h.in PCbuild/rt.bat | xargs sed -i 's/python3\(\.\?\)[0-9]\+/python3\19/g'
    • 编辑 .github/ISSUE_TEMPLATE/ 中的 bug.yml 和 crash.yml 问题模板，以将新分支添加到“versions”下拉菜单中。
    • 将这些更改提交到主分支
      git status
git add ...
git commit -m 'Bump to 3.9.0a0'
  • 在此目录中再次执行 git status。

    你不应该看到任何文件，也就是说，你的工作目录中最好不要有任何未提交的更改。

  • 提交并推送到主仓库
    # Do a dry run first.

# For feature pre-releases prior to a **new branch** release,
#   i.e. a feature alpha release:
git push --dry-run --tags  git@github.com:python/cpython.git main
# If it looks OK, take the plunge.  There's no going back!
git push --tags  git@github.com:python/cpython.git main

# For a **new branch** release, i.e. first beta:
git push --dry-run --tags  git@github.com:python/cpython.git 3.X
git push --dry-run --tags  git@github.com:python/cpython.git main
# If it looks OK, take the plunge.  There's no going back!
git push --tags  git@github.com:python/cpython.git 3.X
git push --tags  git@github.com:python/cpython.git main

# For all other releases:
git push --dry-run --tags  git@github.com:python/cpython.git 3.X
# If it looks OK, take the plunge.  There's no going back!
git push --tags  git@github.com:python/cpython.git 3.X
  • 如果这是一个 **新分支** 发布，请为新创建的分支 (3.X) 添加一个 Branch protection rule。查看上一个发布分支 (3.X-1) 的值并将其用作模板。https://github.com/python/cpython/settings/branches

    另外，为 GitHub 仓库添加 3.x 和 needs backport to 3.X 标签。https://github.com/python/cpython/labels

  • 现在你可以重新启用 GitHub 上针对管理员的分支设置强制执行。回到 Settings | Branch 页面

    https://github.com/python/cpython/settings/branches

    “编辑”你正在发布的分支的设置。重新勾选“包括管理员”框，然后按底部的“保存更改”按钮。

现在是时候调整网站了。很抱歉，几乎没有自动化。

要执行这些步骤，你必须具有编辑网站的权限。如果你没有，请联系 pydotorg@python.org 的人，获取适当的权限。

  • 登录 https://pythonlang.cn/admin
  • 为发布创建一个新的“release”。目前“Releases”在“Downloads”下排序。

    最简单的方法可能是复制现有 Python 发布“页面”中的字段，并边复制边编辑。

    你可以使用 Markdown 或 reStructured Text 来描述你的发布。前者更简洁，而后者对引用 PEPs 等事物具有巧妙的集成。

    将表单上的“发布页面”字段留空。

  • “保存”发布。
  • 用可下载文件填充发布。

    我的朋友兼我的好帮手 Georg Brandl 制作了一个可爱的工具，名为 add_to_pydotorg.py。你可以在 python/release-tools 仓库中找到它（就在 release.py 旁边）。你在 downloads.nyc1.psf.io 上运行该工具，就像这样

    AUTH_INFO=<username>:<python.org-api-key> python add_to_pydotorg.py <version>

    这会遍历 <version> 的正确下载目录，查找标有 <version> 的文件，并使用这些文件填充网站上相应“release”的“Release Files”。请注意，每次运行时，它都会清除相关版本的“Release Files”。你可以从任何你喜欢的目录运行它，并且如果文件发生更改，你可以根据需要运行多次。在 dl-files 上的主目录中保留一份副本并保持其最新。

    如果向发布添加了新类型的文件，则需要有人更新 add_to_pydotorg.py，以便它能够识别这些新文件。（最好在删除文件类型时也更新 add_to_pydotorg.py。）

    该脚本还将签署所有在此之前未通过 Sigstore 签署的剩余文件。同样，如果发生这种情况，请务必使用你的 @python.org 地址进行此过程。更多信息：https://pythonlang.cn/download/sigstore/

  • 如果 CDN 已经缓存了没有文件存在的下载页面版本，你可以使用以下命令使缓存失效
    curl -X PURGE https://pythonlang.cn/downloads/release/python-XXX/
  • 如果这是 **最终** 版本
    • 将新版本添加到 *Python Documentation by Version* 页面 https://pythonlang.cn/doc/versions/，并从任何“开发中”部分中移除当前版本。
    • 对于 3.X.Y，编辑所有之前的 X.Y 版本的页面，使其指向新版本。这包括发布在 Downloads -> Releases 条目中的内容字段
      Note: Python 3.x.(y-1) has been superseded by
`Python 3.x.y </downloads/release/python-3xy/>`_.

      并且，对于那些有单独发布页面条目的发布（正在逐步淘汰这些？），也更新这些页面，例如 download/releases/3.x.y

      Note: Python 3.x.(y-1) has been superseded by
`Python 3.x.y </download/releases/3.x.y/>`_.
    • 更新“当前预发布测试版本网页”。

      有一个页面列出了所有当前正在测试的 Python 版本

      每次发布时，你都不得不以某种方式更新此页面

      • 如果你正在发布 3.x.0 之前的版本，你应该将其添加到此页面，并根据需要删除 3.x 的上一个预发布版本。
      • 如果你正在发布 *3.x.0 final*，你需要从本页面中删除预发布版本。

      这在基于 Django 的网站的“Pages”类别中，通过该 UI 查找有点麻烦。然而！如果你已经登录到管理界面（此时你应该已经登录），Django 将非常方便地在页面顶部添加一个“编辑此页面”链接。因此，你可以简单地点击上面的链接，点击“编辑此页面”链接，并根据需要进行更改。多么方便！

    • 如果合适，更新“Python 文档版本”页面

      这列出了所有 Python 版本的发布，并链接到它们的静态（非每日构建）在线文档。底部有一个开发中版本的列表，所有 alpha/beta/RC 都应放在这里。是的，你应该能够点击上面的链接，然后按下闪亮、令人兴奋的“编辑此页面”按钮。

  • 在 discuss.python.org 上撰写公告。这是模糊的部分，因为自动化程度不高。你可以使用较早的公告作为模板，但要编辑其内容！
  • 公告发布到 Discourse 后，将等效内容发送到以下邮件列表
  • 同时将公告发布到 Python Insider 博客。要添加新条目，请转到 你的 Blogger 主页。
  • 更新 发布 PEPs（例如 719）中的发布日期。
  • 更新 https://github.com/python/cpython/issues 上的标签
    • 将所有 deferred-blocker 问题重新标记为下一个版本的 release-blocker。
    • 审查开放问题，因为这可能会发现潜在的阻碍性 bug，此外还能提醒人们修复他们遗忘的简单问题。
  • 你可以从你的仓库克隆中删除远程发布克隆分支。
  • 如果这是一个 **新分支** 发布，你需要确保开发基础设施的各个部分都为新分支进行了更新。这些包括
    • 更新新分支的问题跟踪器：将新版本添加到版本列表中。
    • 更新 开发指南 以反映新的分支和版本。
    • 创建一个 PR 以更新 下载页面 上的支持发布表格（参见 python/pythondotorg#1302）。
    • 确保为新分支定义了构建机器人（联系 Łukasz 或 Zach Ware）。
    • 确保根据需要为新分支更新了各种 GitHub 机器人。特别是，确保可以回溯到新分支（联系 核心工作流团队）。
    • 审查 main 和新发布分支的最新提交历史，以识别并回溯在发布工程阶段可能已合并到 main 分支中且应存在于发布分支中的任何合并。
    • 验证 CI 是否适用于 main 和新发布分支的新 PR，以及发布分支是否受到适当保护（没有直接推送等）。
    • 验证 在线文档 是否正确构建（网站上完全构建可能需要长达 24 小时）。

接下来做什么？

  • 验证！假装你是一个用户：从 www.python.org 下载文件，并用它构建 Python。这一步很容易被忽略，我们曾多次遇到无用的发布文件。有一次，一个通用的服务器问题导致所有文件神秘损坏；有一次，源 tarball 构建不正确；不止一次，SF 上的文件上传过程截断了文件；等等。
  • 欢庆。畅饮。尽情欢乐。写一个像这样的 PEP。或者像 Guido 一样去度假。

你刚刚发布了一个 Python 版本！

进入生命周期结束阶段

根据现行政策，一个发布分支通常在其首次发布五年后达到生命周期结束状态。该政策在 Python 开发者指南 中有更详细的讨论。当达到生命周期结束时，需要执行许多任务，这些任务要么由你作为发布经理直接执行，要么通过确保其他人执行来完成。其中一些任务包括

  • 选择性地进行最终发布，以发布任何剩余的未发布更改。
  • 通过创建其当前 HEAD 的标签，然后从 CPython 仓库中删除该分支来冻结发布分支的状态。当前 HEAD 应在或超过该分支的最终安全发布版本
    git fetch upstream
git tag --sign -m 'Final head of the former 3.3 branch' 3.3 upstream/3.3
git push upstream refs/tags/3.3
  • 如果一切看起来正常，请删除分支。这可能需要拥有仓库管理员权限的人员协助
    git push upstream --delete 3.3  # or perform from GitHub Settings page
  • 从下载页面的“活动 Python 发布”列表中删除该发布。为此，登录 python.org 的管理页面，导航到 Boxes，然后编辑 downloads-active-releases 条目。删除你的发布相关的 HTML 段落。（你可能需要执行 curl -X PURGE 技巧来清除缓存，如果你想确认更改正确。）
  • 为已停用的分支的 python.org 上的每个发布页面添加已停用通知。例如
  • 在 开发者指南 中，将分支状态设置为生命周期结束，并更新或删除开发指南中对该分支的其他引用。
  • 从 问题跟踪器 中退役该发布。任务包括
    • 将此版本的问题更新到下一个受支持的版本
    • 从版本列表中删除版本标签
    • 删除已停用版本的 needs backport to 标签
    • 审查并处理标记为该分支的开放问题
  • 运行在线文档的最终构建，以添加生命周期结束横幅
  • 在常用地方宣布分支退役
    • discuss.python.org
    • 邮件列表 (python-dev, python-list, python-announcements)
    • Python Dev blog
  • 享受你的退休生活，并沐浴在出色工作的荣耀中！

Windows 注意事项

Windows 有 MSI 安装程序，各种 Windows 版本都有“特殊限制”，Windows 安装程序还打包了预编译的“外部”二进制文件（Tcl/Tk、expat 等）。

安装程序作为 Azure Pipeline 的一部分进行测试。过去，这些步骤是手动执行的。我们保留它以供后代使用。

在上传安装程序的同时，WE 会两次安装 Python：一次安装到安装程序建议的默认目录中，另一次安装到名称中包含嵌入空格的目录中。对于每次安装，WE 都会从 DOS 命令行运行完整的回归测试套件，并且分别带和不带 -0 选项。对于维护版本，WE 还会测试升级安装是否成功。

WE 还会尝试“开始”->“菜单”->“Python 组”下创建的 *每个* 快捷方式。以这种方式尝试 IDLE 时，你需要验证“帮助”->“Python 文档”是否有效。以这种方式尝试 pydoc（“模块文档”开始菜单项）时，请确保“启动浏览器”按钮有效，并确保你可以搜索一个随机模块（例如“random”<眨眼>），然后“转到所选”按钮有效。

这里可能会出那么多问题真是令人惊讶——而更令人惊讶的是，最后一刻的提交经常会破坏其中一些东西。如果你是“Windows 技术人员”，请记住你很可能是唯一一个定期在 Windows 上测试的人，而且 Windows 就是一团糟。

对每个目标架构重复测试。尝试使用管理员账户和普通用户（非高级用户）账户。

来源：https://github.com/python/peps/blob/main/peps/pep-0101.rst

最后修改：2025-08-14 14:55:05 GMT