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 的 Beta 版和候选发布版阶段重叠，因此未版本化。
  • 接下来的**七个月**用于版本化的 Alpha 发布，其中增量添加新功能并包含错误修复。
  • 随后的**三个月**用于四个版本化的 Beta 发布，在此期间**不能**添加新功能，但仍包含错误修复。
  • 最后的**两个月**用于两个或更多（如有必要）的候选发布版，并以 Python 3.X.0 最终版的发布结束。

2 年全面支持，3 年安全修复

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

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

注意：2 年的全面支持从 Python 3.13 开始。Python 3.9 - 3.12 版本按照 1 年半全面支持，然后是 3 年半安全修复的日历运行。

年度发布节奏

Python 3.(X+1).0 的功能开发在 Python 3.X.0 Beta 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 candidate 1：2020年8月10日，星期一
  • 3.9.0 candidate 2：2020年9月14日，星期一
  • 3.9.0 final：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 candidate 1：2021年3月29日，星期一
  • 3.9.0 candidate 2：2021年4月5日，星期一（如有必要）
  • 3.9.0 final：2021年4月19日，星期一（晚 6 个月）

相关策略

弃用

当前关于重大更改的策略假设在弃用功能从 Python 中移除或默认启用 __future__ 行为之前至少进行两次发布。这在 PEP 387 中有记载。

此 PEP 提议在进行重大更改之前**至少**保持两次发布的策略。

指导委员会的任期

当前 PEP 13 的措辞规定“每次功能发布后都会选举新的委员会”。此 PEP 提议保持此策略，因为它将导致一致的选举时间表。

发布经理的任期

当前不成文的惯例是由一位发布经理处理两个 Python 功能版本。此 PEP 提议保持此策略，并允许在获得指导委员会和发布经理委员会批准的情况下，将任期延长至更多版本。

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

基本原理和目标

此更改提供以下优势

  • 使发布更小：由于将发布节奏加倍并不能使我们的可用开发资源加倍，因此连续发布在功能方面将更小；
  • 更快地将功能和错误修复交付给用户；
  • 通过减少任何单个版本中的更改范围，为用户创建更渐进的升级路径；
  • 为发布创建可预测的日历，其中最终版本始终在十月（即年度核心冲刺之后），Beta 阶段在五月下旬开始（即 PyCon US 冲刺之后），这对于需要计划将 Python 参与纳入其日历的核心开发人员尤为重要；
  • 由于担心功能“延期 18 个月”的风险，减少了在“Beta 1”之前匆忙推出功能的冲动；
  • 允许将 Python 发布管理的计划与像 Fedora 这样的外部发行商同步，他们历来在早期发现核心 Python 以及第三方库中的回归方面非常有帮助，从而推动社区从第一天开始就支持最新版本的 Python；
  • 增加了明确的 Alpha 发布阶段，这提供了新功能进度的有意义的快照；
  • 显著减少了隐式“alpha 0”发布阶段，无论如何，它对新开发的用处有限（它与当前开发的尚未发布的版本的 Beta 版重叠）。

非目标

采用年度发布日历允许自然地切换到日历版本控制，例如将 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 个月的发布节奏

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

  • 每年不规则的发布日期使得贡献安排更加困难；
  • 由于“错过发布”所带来的压力，在 Beta 1 之前（甚至之后！）产生了一波匆忙的提交；
  • 讽刺的是，在 Beta 1 之后，它制造了一种在下次发布前有“充足时间”的假象，而时间无论如何都会很快过去；
  • 它导致工作流的某些元素执行得如此之少，以至于它们没有明确的文档，更不用说自动化了。

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

  • 它创建了许多新功能的版本，其中一些是明确不兼容的，一些是意外不兼容的，这使得每次升级成本相对较高；
  • 它将功能和不兼容的错误修复搁置一年多才提供给用户；更具体地说
  • 它导致每个“点零”发布对用户来说都格外危险。虽然我们提供并建议使用 Alpha 和 Beta 版进行测试，但“点零”是许多用户首次发布的给定 Python 版本。一个版本在功能方面越大，在“点零发布”中隐藏的潜在问题就越多。

将发布节奏翻倍，实现功能版本之间相隔 9 个月

这最初在 PEP 596 中提出，但因过于不规则和过短而被拒绝。这将不会带来常规发布日历的任何好处，但会缩短所有开发阶段，特别是 Beta + RC 阶段。这被认为是危险的。

保持“4 个月内 4 个 Beta 版和一个最终的候选发布版”

虽然这将使发布日历更清晰一些，但 这将使 Fedora 等外部发行商很难尽快发布最新版本的 Python。我们正在调整 Python 的日历，希望这将使 Fedora 能够在开发过程中将最新版本的 Python 与最新版本的 Fedora 集成，从而使这两个项目都更好。

放慢发布速度，但不冻结 Beta 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