减小功能交付批次的大小

当多个大的变更一起交付时，可能需要进行复杂的调查才能确定出现的任何新问题的根本原因。批次越大，遇到问题的可能性也越大，因为它们包含更大块相对未经测试的代码。

简化这些调查并减少用户遇到问题的可能性最简单的方法是减小交付批次的大小。

PEP 602 提议通过直接的方法解决此问题：将 CPython 的典型批次大小减少 50%，每次交付 12 个月的变更，而不是累积 18 个月以上的变更。

PEP 605 提议通过定期向选择运行滚动 Beta 版本的 Python 用户子集交付 2 个月的变更来解决此问题（类似于运行 Windows Insider 版本而不是 Windows 零售版本，或运行 Debian testing 而不是 Debian stable）。

缩短功能交付的延迟

当只有稳定版本获得大量用户采用，并且稳定版本之间存在很长一段时间时，这会给开发人员带来极大的诱惑，促使他们将变更推送到稳定版本中，即使这些变更尚未真正准备好投入一般使用。

PEP 602 提议通过将稳定版本之间的时间间隔缩短至 12 个月而不是 18 个月来解决此问题。

PEP 605 提议通过积极创建一个定期安装和使用 CPython Beta 版本的 Python 用户社区来解决此问题，从而激励核心开发人员在预发布周期中更早地发布变更，以便在功能锁定在稳定版本中之前获得反馈。

使发布节奏与日历年保持一致

虽然当前的发布节奏名义上是 18-24 个月，但实际上它一直倾向于该范围的 18 个月末。这意味着预发布和最终版本的目标日期在不同版本之间会发生变化，唯一记住它们的方法是查看发布 PEP，或者将这些日期添加到日历中。这对于个人志愿者和企业贡献者来说都很麻烦，也使得与 PyCon US（通常是四月/五月）和现在每年举行的核心开发冲刺（通常是九月）等活动保持一致变得复杂。

PEP 602 提议通过每年 10 月发布一个新版本，并以此为基础制定每年的预发布日历来解决此问题。

PEP 605 提议通过在发布年份（8 月发布新稳定版本）和非发布年份（只发布维护版本和新的滚动 Beta 版本）之间交替来解决此问题。

改进预发布设计反馈周期

设计核心解释器和标准库 API 变更的挑战之一是，能够提供关于每夜构建和当前预发布版本的反馈的用户群相对有限。这意味着许多用户反馈直到 API 设计已在完整的 X.Y.0 版本中发布之后才收到。

如果 API 是常规 API，那么废弃周期意味着纠正此时识别出的任何设计错误可能需要数年时间。将 API 标记为临时 API 名义上提供了一种避免此限制的方法，但实际利用这种自由会导致其他问题。

PEP 602 提议通过在前一个稳定版本发布后立即开始 Alpha 阶段来解决此问题。

PEP 605 提议通过积极推广将 CPython 预发布版本用于运行生产工作负载（不仅仅用于库和应用程序兼容性测试），并根据需要调整预发布管理流程以使其成为合理的事情来解决此问题。

（注：一些标准库 API 最初可以作为单独版本化的包通过 PyPI 发布，然后才合并到标准库中。本节更多地关注低级 API 和非库功能，这些功能不适用于获取早期设计反馈的方法）

对已跳过某些版本的用户和再分发商的影响

目前已经存在并非所有用户和再分发商都更新到每个已发布的 CPython 发布系列的情况（例如，Debian stable 和 Ubuntu LTS 有时会跳过版本，因为它们的 24 个月发布周期与 CPython 通常的 18 个月周期不匹配）。

PEP 602 中更快的 12 个月完整发布节奏意味着此类别中的用户最终可能会跳过两个版本，而以前只会跳过一个。然而，延长的废弃通知期意味着跳过一个版本不应再导致错过废弃警告。

PEP 605 中较慢的 24 个月完整发布节奏可能会将历史上属于此类别的一些用户转移到“更新到每个稳定版本”类别中。

对更新到每个版本的用户和再分发商的影响

许多 Python 用户从未安装预发布版本，但都会在发布后某个时候更新到每个稳定发布系列。

PEP 602 旨在通过将版本之间的最小间隔保持为 12 个月，并为每个版本保留 18 个月的完全支持期来缓解对此组成员的潜在负面影响。

为每个发布分支保留 18 个月的完全支持期意味着这些分支将花费大致相同的时间在完全支持和仅安全修复模式下（分别为约 18 个月和约 42 个月）。

PEP 605 旨在通过增加预发布期间的使用来缓解对此组成员的潜在负面影响，以实现更稳定的最终版本，并在发布时获得更广泛的生态系统支持。

在 24 个月的发布节奏下，每个发布分支将按比例花费更多时间在完全支持模式下，更少时间在仅安全修复模式下（分别为约 24 个月和约 36 个月）。

关于对该组影响的详细讨论将留给各个 PEP。

对 CPython 每夜构建的用户和再分发商的影响

尽管这样做有困难，但已经有一些用户和再分发商接受了直接使用或发布 CPython master 分支的挑战。

PEP 602 和 PEP 605 都不应直接影响此组，但 PEP 605 中的滚动发布流提案旨在降低更多用户采用这种使用方式的障碍，允许他们采用经过测试的滚动 Beta 流，而无需直接使用 master 分支。

对第三方库维护者的影响

对于第三方库的维护者来说，支持复杂性的关键来源是广泛使用的不同 Python 版本的数量。

PEP 602 旨在通过将完整版本之间的最小间隔保持为 12 个月来缓解对此组成员的潜在负面影响。

PEP 605 旨在通过将完整版本之间的间隔增加到 24 个月，保留当前政策，即在其继任者发布后不久将每个发布分支转移到仅安全修复模式，并保留新的滚动发布流的“Beta”命名方案（至少对于 Python 3.9 发布周期）来缓解对此组成员的潜在负面影响。

关于对该组影响的详细讨论将留给各个 PEP。