减少功能交付批次的大小

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

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

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

PEP 605 建议通过定期向选择使用滚动发布流的 beta 版本的 Python 用户子集交付 2 个月的更改来解决此问题（类似于运行 Windows 预览体验成员构建而不是 Windows 零售版本，或运行 Debian testing 而不是 Debian stable）。

减少功能交付的延迟

当只有稳定版本获得显著的用户采用，并且稳定版本之间的时间间隔很长时，就会极大地诱惑开发人员在更改真正准备好用于通用使用之前将其推送到稳定版本中。

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

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

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

虽然目前的发布节奏名义上是 18-24 个月，但实际上它始终接近 18 个月的范围。这意味着预发布和最终版本的目标日期在每次发布时都会发生变化，并且记住它们的唯一方法是查看发布 PEP，或者将这些日期添加到日历中。这对于个人志愿者和企业贡献者来说都很烦人，并且还会使与 PyCon US（通常在 4 月/5 月）和现在每年的核心开发冲刺（通常在 9 月）等活动保持一致变得复杂。

PEP 602 建议每年 10 月发布一个新版本，并以此为基础为每年的预发布日历。

PEP 605 建议在发布年份（在 8 月发布新的稳定版本）和非发布年份（仅发布维护版本和新的滚动 beta 版本）之间交替进行。

改进预发布设计反馈周期

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

如果 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。