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

Python 增强提案

PEP 602 – Python 年度发布周期

作者:
Łukasz Langa <lukasz at python.org>
PEP 代表:
Brett Cannon <brett at python.org>
讨论至:
Discourse 线程
状态:
活跃
类型:
流程
创建于:
2019 年 6 月 4 日
Python 版本:
3.9
发布历史:
2023 年 10 月 9 日
决议:
Python-Dev 线程
目录

摘要

本文件描述了从 Python 3.9 开始的 Python 发布日历的更改。此更改加速了发布节奏，使得特性版本可以预测地每十二个月发布一次，每年十月发布一次。

实现

十七个月开发一个特性版本

本 PEP 建议 Python 3.X.0 将开发大约 17 个月

  • 前 *五个月* 与 Python 3.(X-1).0 的测试版和发布候选版阶段重叠，因此没有版本。
  • 接下来的 *七个月* 用于版本化的 Alpha 版本，其中逐步添加新特性并包含错误修复。
  • 接下来的 *三个月* 用于四个版本化的测试版，在此期间 **不能添加任何新特性**，但仍然包含错误修复。
  • 最后 *两个月* 用于两个发布候选版（如果有必要，可以更多），并最终发布 Python 3.X.0 的最终版本。

两年完整支持，三年安全修复

Python 3.X.0 发布后，3.X 系列将维护五年

  • 在 *前二十四个月*（两年）中，它将收到错误修复更新，并且完整版本（Windows 和 macOS 的源代码和安装程序）大约每隔一个月发布一次。
  • 在接下来的 *三十六个月*（三年）中，它将收到安全更新，并且仅发布源代码，根据需要发布（没有固定的节奏）。
  • 最后一个仅发布源代码的版本将在 3.X.0 发布 *五年* 后发布。

注意：两年完整支持从 Python 3.13 开始。Python 版本 3.9 - 3.12 按照一个日历操作，其中包含 1.5 年的完整支持，以及 3.5 年的安全修复。

年度发布节奏

Python 3.(X+1).0 的特性开发从 Python 3.X.0 测试版 1 发布时开始。这在 Python 特性版本之间创建了一个十二个月的间隔。

示例

  • 3.9 开发开始：2019 年 6 月 4 日，星期二
  • 3.9.0 alpha 1：2019 年 10 月 14 日，星期一
  • 3.9.0 alpha 2：2019 年 11 月 18 日，星期一
  • 3.9.0 alpha 3：2019 年 12 月 16 日，星期一
  • 3.9.0 alpha 4：2020 年 1 月 13 日，星期一
  • 3.9.0 alpha 5：2020 年 2 月 17 日，星期一
  • 3.9.0 alpha 6：2020 年 3 月 16 日，星期一
  • 3.9.0 alpha 7：2020 年 4 月 13 日，星期一
  • 3.9.0 beta 1：2020 年 5 月 18 日，星期一（此后不再添加新特性。）
  • 3.9.0 beta 2：2020 年 6 月 8 日，星期一
  • 3.9.0 beta 3：2020 年 6 月 29 日，星期一
  • 3.9.0 beta 4：2020 年 7 月 20 日，星期一
  • 3.9.0 候选版 1：2020 年 8 月 10 日，星期一
  • 3.9.0 候选版 2：2020 年 9 月 14 日，星期一
  • 3.9.0 正式版：2020 年 10 月 5 日，星期一
../_images/pep-0602-example-release-calendar.png

图 1. 年度发布周期对日历的影响。

相比之下，如果本 PEP 被拒绝，而 Python 保持当前的发布计划

  • 3.9 开发开始：2019 年 6 月 4 日，星期二
  • 3.9.0 alpha 1：2020 年 8 月 3 日，星期一（晚 10 个月）
  • 3.9.0 alpha 2：2020 年 9 月 7 日，星期一
  • 3.9.0 alpha 3：2020 年 10 月 5 日，星期一
  • 3.9.0 alpha 4：2020 年 11 月 2 日，星期一
  • 3.9.0 beta 1：2020 年 11 月 30 日，星期一（晚 6 个月）
  • 3.9.0 beta 2：2021 年 1 月 4 日，星期一
  • 3.9.0 beta 3：2021 年 2 月 1 日，星期一
  • 3.9.0 beta 4：2021 年 3 月 1 日，星期一
  • 3.9.0 候选版 1：2021 年 3 月 29 日，星期一
  • 3.9.0 候选版 2：2021 年 4 月 5 日，星期一（如果有必要）
  • 3.9.0 正式版：2021 年 4 月 19 日，星期一（晚 6 个月）

相关策略

弃用

当前关于重大更改的策略假定至少有两个版本才能从 Python 中删除弃用的特性或默认启用 __future__ 行为。这在 PEP 387 中有记录。

本 PEP 建议保持此策略，即在进行重大更改之前 **至少** 有两个版本。

指导委员会任期

当前 PEP 13 的措辞指出，“每个特性版本发布后都会选举新的委员会”。本 PEP 建议保持此策略，因为它将导致一致的选举时间表。

发布经理任期

当前的非正式惯例是，单个发布经理负责处理 Python 的两个特性版本。本 PEP 建议保持此策略，允许在指导委员会和发布经理委员会的批准下，将任期延长到更多版本。

尤其是，由于本 PEP 由现任发布经理撰写，并且其影响将缩短发布经理的任期，因此作者愿意管理第三个特性版本的发布，以弥补中断。

基本原理和目标

此更改提供了以下优势

  • 使版本更小：由于将节奏翻倍不会使我们可用的开发资源翻倍，因此连续版本在特性方面将更小；
  • 更快地将特性和错误修复交付到用户手中；
  • 通过减少单个版本中的更改范围，为用户创建更平滑的升级路径；
  • 为发布创建可预测的日历，其中最终版本始终在十月发布（因此在年度核心冲刺之后），测试版阶段从五月下旬开始（因此在 PyCon US 冲刺之后），这对需要在其日历中规划 Python 参与的核心开发人员来说尤其重要；
  • 减少了由于“错过 18 个月”的风险而导致在“测试版 1”之前匆忙添加特性的冲动；
  • 允许 Python 发布管理的时间表与 Fedora 等外部发行商同步，这些发行商在从一开始就发现核心 Python 和第三方库中的回归方面一直非常有帮助，帮助社区向前发展以支持最新版本的 Python；
  • 增加了显式的 Alpha 版本阶段，这提供了对新特性进展的有意义的快照；
  • 显着减少了隐式的“Alpha 0”发布阶段，无论如何，该阶段对新开发的用处有限（它与 *当前正在开发* 的尚未发布的版本的测试版重叠）。

非目标

采用年度发布日历允许自然地切换到日历版本，例如，将 Python 3.9 称为“Python 3.20”，因为它是在 20 年 10 月发布的，依此类推（“Python 3.23”将在 23 年 10 月发布）。

虽然切换到日历版本很容易，可以被视为年度发布周期的优势，但本 PEP 并不主张或反对更改 Python 的版本方式。如果采用年度发布周期，版本问题将在单独的 PEP 中处理。

非风险

此更改不会缩短当前记录的 Python 版本的支持日历，无论是错误修复版本还是安全修复。

此更改不会加速开发速度。Python 不会更快地变得不兼容或更快地积累新特性。只是特性将在开发过程中更平滑地发布。

因此，虽然此更改为用户提供了更快的升级能力，但它并不强制要求用户这样做。例如，如果他们每隔一个版本升级一次，他们在 Python 中的体验将与当前情况类似。

风险

Python 再发行

这需要更改集成商（如 Linux 发行版）在其系统中发布 Python 的方式。

测试矩阵

最终，这将使想要支持所有正在积极支持的 Python 版本的库和应用程序维护者的测试矩阵增加一到两个

../_images/pep-0602-overlapping-support-matrix.png

图 2. 18 个月发布节奏与 12 个月发布节奏的测试矩阵

当前发布周期的“由发布经理自行决定提供的扩展错误修复支持”阶段没有被编码。事实上，PEP 101 目前指出，在 Python 3.(X+1).0 发布后，只为 Python 3.X.0 发布最后一个错误修复版本。然而，在实践中，至少在过去四个 Python 3 版本中，大约有六个月与下一个版本的稳定版本重叠。图 2 包含此信息是为了证明，使用 12 个月发布节奏，稳定版本发布之间的重叠并不是什么新鲜事。

其他策略可能依赖于发布节奏

尽管之前的一节已经解决了一些已识别的依赖策略，但完全有可能存在其他一些隐式依赖于 Python 版本发布时间的领域。

被拒绝的意见

保持当前的 18 个月发布节奏

这对核心开发人员和最终用户来说都是不可取的。从核心开发人员的角度来看

  • 由于每年不规则的发布日期，这使得贡献时间安排变得更加困难；
  • 由于“错过发布”带来的压力，这会在测试版 1 之前（甚至之后！）产生大量匆忙提交的代码；
  • 具有讽刺意味的是，在测试版 1 之后，这会产生一种错误的感觉，即在下次发布之前有“充足的时间”，但时间总是过得很快；
  • 这会导致工作流程中的某些元素很少执行，以至于没有明确记录，更不用说自动化了。

更重要的是，从用户的角度来看

  • 这会创建包含许多新特性的版本，有些明确不兼容，有些意外不兼容，这使得每次升级的成本都相对较高；
  • 这会让特性和不兼容的错误修复沉淀一年多，然后才能提供给用户；更具体地说
  • 这会导致每个“点零”版本对用户来说都格外冒险。虽然我们提供了 Alpha 版和测试版的测试，并建议进行测试，但对于许多用户来说，“点零”是特定 Python 版本的第一个版本。版本的功能越强大，隐藏在“点零版本”中的潜在问题就越多。

将发布节奏翻倍以实现特性版本之间 9 个月的间隔

这最初是在 PEP 596 中提出的，但由于过于不规则和时间过短而被拒绝。这不会带来定期发布日历的任何好处，但会缩短所有开发阶段，尤其是测试版 + 发布候选版阶段。这被认为很危险。

保持“4 个月 4 个测试版以及最后一个月用于发布候选版”

虽然这会让发布日历更简洁，但会让 Fedora 等外部发行版很难尽快发布最新版本的 Python。我们正在调整 Python 的日历，希望这将使 Fedora 能够在开发过程中将最新版本的 Python 与最新版本的 Fedora 集成，从而使这两个项目都得到改善。

减缓发布速度，但不要在测试版 1 中冻结功能开发

这在 PEP 598 中有描述。该提案包括“增量功能发布”等非标准概念，这使得它难以理解。提出的优势尚不清楚，而该方案的陌生性确实存在用户和集成商混淆的风险。

长期支持版本

每个版本的 Python 实际上都是长期支持：它支持五年，前十八个月允许定期修复错误和安全更新。在剩下的时间里，安全更新会被接受并立即发布。

将来不计划像 Python 2.7 那样提供扩展支持。

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

上次修改时间：2024-05-28 05:47:01 GMT