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

Python 增强提案

PEP 101 – Python 版本发布指南

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

替换:
102
目录

摘要

发布 Python 版本是一个令人兴奋且疯狂的过程。你听说过“牧羊犬”这个词吗？想象一下，试图给这些咕噜咕噜的小生物套上马鞍，然后骑着它们进城，还有一些同伴紧紧地粘在你的背上，用新磨尖的爪子固定着。至少它们很可爱，你提醒自己。

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

你需要的东西

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

  • 一个 GPG 密钥。

    Python 版本使用 GPG 进行数字签名；你需要一个密钥，希望它至少与其他发布经理中的一个在“信任网”中。

  • 一堆软件
    • 一个 python/release-tools 仓库的检出。它包含一个 requirements.txt 文件，你需要先从中安装依赖项。之后，你可以在仓库中启动脚本，本文档后面会介绍。
    • 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+
  • 最终版本
  • new branch
  • begin bugfix mode
  • begin security-only mode
  • 生命周期结束

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

在下文的描述中，特定于版本类型的步骤将相应标记，目前为**新分支**和**最终版本**。

如何发布版本

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

注意

强烈建议 RM 在发布前一天联系专家。由于世界是圆的，每个人都生活在不同的时区，因此 RM 必须确保在足够的时间内创建发布标签，以便专家能够裁剪二进制发布版本。

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

在尽可能的情况下，发布步骤是自动化的，并由发布脚本引导，该脚本位于一个单独的仓库中：python/release-tools。

我们在下面的示例中使用以下约定。在给出版本号的情况下，它采用 3.X.YaN 的形式，例如 Python 3.13.0 alpha 3 为 3.13.0a3，其中“a” == alpha，“b” == beta，“rc” == 发布候选版本。

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

这有助于执行几个自动编辑步骤，并指导你执行一些手动编辑步骤。

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

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

  • 检查是否存在任何严重错误。

    转到 https://github.com/python/cpython/issues 并查找任何可能阻止此版本的未解决错误。你将查看两个相关的标签

    release-blocker
    直接阻止发布。如果存在任何未解决的 release-blocker 错误，你都不能发布任何版本。
    deferred-blocker
    不阻止此版本，但会阻止未来的版本。如果存在任何未解决的 deferred-blocker 错误，你都不能发布最终版本或候选版本。

    审查 release-blocker 并解决它们、将其降级为 deferred，或停止发布并请求社区协助。如果你正在发布最终版本或候选版本，请对任何未解决的 deferred 执行相同的操作。

  • 检查稳定的 buildbot。

    转到 https://buildbot.python.org/all/#/release_status

    查看你正在发布的版本的 buildbot。忽略任何脱机的 buildbot（或通知社区，以便重新启动它们）。如果剩余的是（大部分）绿色的 buildbot，那么你就可以开始了。如果你有未脱机的红色 buildbot，你可能希望推迟发布，直到它们被修复。审查问题并使用你的判断，考虑你是否正在发布 alpha、beta 或最终版本。

  • 创建发布克隆。

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

    对于**最终版本**或**发布候选版本 2+** 版本，如果你要从自上次 rc 以来合并的所有更改中挑选一部分更改以用于下一个 rc 或最终版本，则应从最新的发布候选版本标签（即 v3.8.0rc1）开始创建发布工程分支。然后，你将根据需要将标准发布分支中的更改 cherry-pick 到发布工程分支中，然后照常进行。如果你要采用自上一个 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 应为 0（3.6.0）。

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

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

  • 确保所有更改都已提交。（release.py --bump 不会为您检入其更改。）
  • 检查版权声明中的年份。如果上一次发布是在去年的某个时候，请在多个地方将当前年份添加到版权声明中
    • README
    • LICENSE（确保在 main 和分支上更改）
    • Python/getcopyright.c
    • Doc/copyright.rst
    • Doc/license.rst
    • PC/python_ver_rc.h 为 Windows 设置 DLL 版本资源（在您右键单击 DLL 并选择“属性”时显示）。这不是 C 包含文件，而是 Windows“资源文件”包含文件。
  • 对于**最终**主要版本，编辑 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

    这将执行 git tag 命令，并使用 -s 选项，以便存储库中的发布标签使用您的 GPG 密钥签名。出现提示时，选择用于签名发布 tarball 等的私钥。

  • 对于**开始仅限安全模式**和**生命周期结束**版本，请查看这两个文件并在所有活动分支中相应地更新版本。
  • 是时候构建源 tarball 了。使用发布脚本创建源 gzip 和 xz tarball、文档 tar 和 zip 文件以及 GPG 签名文件
    .../release-tools/release.py --export 3.X.YaN

    对于**最终**版本，这可能需要一段时间，它会将所有 tarball 和签名保存在名为 3.X.YaN/src 的子目录中，并将构建的文档保存在 3.X.YaN/docs 中（对于**最终**版本）。

    请注意，脚本将使用 Sigstore 对您的发布进行签名。为此，请使用您的**@python.org** 电子邮件地址。有关更多信息，请参见此处：https://pythonlang.cn/download/sigstore/。

  • 现在，您需要执行非常重要的检查刚刚创建的 tarball 的步骤，以确保完全干净的原始构建通过回归测试。以下是一些最佳步骤
    cd /tmp
tar xvf /path/to/your/release/clone/<version>//Python-3.2rc2.tgz
cd Python-3.2rc2
ls
# (Do things look reasonable?)
ls Lib
# (Are there stray .pyc files?)
./configure
# (Loads of configure output)
make test
# (Do all the expected tests pass?)

    如果您感觉幸运并且有一些时间可以消磨，或者如果您正在进行候选发布或**最终**发布，请运行完整的测试套件

    make buildbottest

    如果测试通过，那么您可以放心 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
  • 通知专家他们可以开始构建二进制文件。

警告

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

  • 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 release.py --export 构建的所有文件到您在 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（如果必要，创建它）。确保它归属下载组并可由组写入。
    • 将发布的 .tgz 和 .tar.xz 文件以及 .asc GPG 签名文件移到适当位置。Win/Mac 二进制文件通常由专家自己放置在那里。

      确保它们对所有人可读。它们也应该可由组写入，并由 downloads 组拥有。

    • 使用 gpg --verify 确保它们完整上传。
    • 如果这是**最终**版本或 rc 版本：将文档 zip 和 tarball 移动到 /srv/www.python.org/ftp/python/doc/3.X.Y[rcA]（如果必要，创建目录），并调整 .../doc 中的“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

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

警告

**停止**并确认

  • 您是否已获得 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 文件，以确保它们现在反映了持续开发所需的发布后值。补丁级别应为发布标签后跟一个 +。此外，如果您将标准发布分支中的更改 cherry-pick 到此版本的发布工程分支，则现在需要手动从 Misc/NEWS.d/next 目录中删除每个 cherry-pick 到您正在处理的发布中的摘要条目，因为该摘要条目现在已捕获到合并的 x.y.z.rst 文件中。否则，该摘要条目将在 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 中所有版本引用。
    • 将任何历史“更新内容”条目从 Misc/NEWS 移动到 Misc/HISTORY。
    • 编辑 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。但请注意，先前版本中最初的 whatsnew/3.x.rst 检入可能不正确，因为最初从一个版本传播到另一个版本的 blurb 中间更改！帮助打破循环：如有必要，请进行以下更改
      -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'
    • 将这些更改提交到 main 分支
      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 仓库中添加一个 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
  • 为该版本创建一个新的“发布”。目前，“发布”在“下载”下排序。

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

    您可以使用 Markdown 或 reStructured Text 来描述您的发布。前者不那么冗长，而后者则可以很好地集成引用 PEP 等内容。

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

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

    您的朋友兼我的朋友 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> 的文件，并使用这些文件填充网站上相应“版本”的“发布文件”。请注意，它每次运行时都会清除相关版本的“发布文件”。您可以在任何喜欢的目录中运行它，并且如果文件发生更改，您可以根据需要运行任意次。在 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 文档”页面 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 正式版，则需要从此页面中删除预发布版本。

      此页面位于基于 Django 的网站的“页面”类别中，通过该 UI 查找它有点麻烦。但是！如果您已经登录到管理界面（此时您应该已经登录），Django 会在页面本身顶部提供一个方便的“编辑此页面”链接。因此，您只需点击上面的链接，点击“编辑此页面”链接，然后根据需要进行更改即可。多么方便！

    • 如果合适，请更新“按版本分类的 Python 文档”页面

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

  • 在 discuss.python.org 上撰写公告。这部分比较模糊，因为自动化程度不高。您可以使用较早的公告作为模板，但请编辑其内容！
  • 在 Discourse 上发布公告后，请将其发送到以下邮件列表
  • 还将公告发布到 Python Insider 博客。要添加新条目，请访问 您的 Blogger 主页，在此处。
  • 使用发布日期更新任何发布 PEP（例如 PEP 719）。
  • 更新 https://github.com/python/cpython/issues 上的标签
    • 将所有 deferred-blocker 问题切换回下一个版本的 release-blocker。
    • 当版本 3.X 进入 Alpha 版时，添加版本 3.X+1。
    • 当版本 3.X 进入 Beta 版时，将非文档功能请求更改为版本 3.X+1。
    • 将发布版本导致不再支持的版本的 issue 更新到下一个受支持的版本。
    • 审查开放的 issue，这可能会发现潜藏的严重错误，此外还可以提醒人们修复他们忘记的简单错误。
  • 您可以从您的仓库克隆中删除远程发布克隆分支。
  • 如果这是一个新分支版本，您需要确保开发基础设施的各个部分已针对新分支进行了更新。其中包括
    • 更新新分支的 issue 跟踪器：将新版本添加到版本列表。
    • 更新 devguide 以反映新的分支和版本。
    • 创建一个 PR 以更新 下载页面 上的受支持版本表（请参阅 python/pythondotorg#1302）。
    • 确保为新分支定义了构建机器人（联系 Łukasz 或 Zach Ware）。
    • 根据需要更新各种 GitHub 机器人，尤其要确保向新分支的反向移植工作正常（联系 core-workflow 团队）。
    • 审查 main 和新发布分支的最新提交历史记录，以识别和反向移植可能在发布工程阶段已合并到 main 分支中并且应该包含在发布分支中的任何合并。

    • 验证 CI 是否适用于 main 和新的发布分支的新 PR，以及发布分支是否受到适当保护（不允许直接推送等）。
    • 验证 在线文档 是否正在正确构建（这可能需要长达 24 小时才能在网站上完成完整的构建）。

下一步是什么？

  • 验证！假装你是用户：从 www.python.org 下载文件，并从中构建 Python。这一步很容易被忽视，并且在一些情况下，我们遇到了无用的发布文件。有一次，通用服务器问题导致所有文件出现神秘损坏；有一次源代码包构建错误；不止一次，SF 上的文件上传过程截断了文件；等等。
  • 欢欣鼓舞。畅饮。尽情欢庆。写一篇像这样的 PEP。或者像吉多一样去度假。

你刚刚发布了一个 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 开发博客
  • 享受您的退休生活，并沉浸在出色工作的喜悦中！

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

上次修改：2024-08-04 14:50:07 GMT