PEP 407 – 新发布周期和引入长期支持版本

作者:: Antoine Pitrou <solipsis at pitrou.net>，Georg Brandl <georg at python.org>，Barry Warsaw <barry at python.org>
状态:: 已延期
类型:: 流程
创建:: 2012年1月12日
更新历史:: 2012年1月17日

摘要

为开源项目找到一个发布周期是一项微妙的练习，需要管理相互矛盾的约束条件：开发人员人力、发布管理志愿者的可用性、用户和第三方打包者的维护便利性、新功能（和行为更改）的快速可用性、在不引入新功能或行为更改的情况下提供错误修复的可用性。

当前的发布周期偏向保守。对于那些重视稳定性而非反应性的用户来说，它已经足够了。本 PEP 试图保持 Python 的商标——稳定性，同时通过引入长期支持版本的概念，提供更流畅的功能发布。

本 PEP 不会尝试更改 2.7 分支的维护周期或发布方案。仅考虑 3.x 版本。

在提议的方案下，将存在两种功能版本（有时称为“次要版本”，例如 3.2 或 3.3）：普通功能版本和长期支持 (LTS) 版本。

普通功能版本将获得零个或最多一个错误修复版本；后者仅在需要修复关键问题时才会提供。

LTS 版本将获得定期错误修复版本，直到下一个 LTS 版本发布。然后它们将进入安全修复模式，直到发布管理员自行决定终止日期。

每 X 个月将发布一个新的功能版本。我们初步建议 X = 6 个月。

LTS 版本将是 N 个功能版本中的一个。我们初步建议 N = 4。

根据这些数据，每 24 个月将发布一个新的 LTS 版本，并持续支持到 24 个月后的下一个 LTS 版本。这与当前每个功能版本 18 个月的错误修复周期略微相似。

更频繁的功能发布意味着每次发布的破坏性更改数量更少。因此，可以大大减少预发布版本（alpha 版和 beta 版）的数量。在常规情况下，两个 alpha 版本和一个 beta 版本可能就足够了。候选版本的数量，像往常一样，取决于最终发布前最后一刻的修复数量。

更多功能发布可能意味着开发和发布管理团队的压力更大。这在数量上可以通过减少预发布版本数量来缓解；在质量上可以通过减少破坏性更改的数量来缓解（这意味着减少潜在的破坏）。较短的功能冻结期（从第一个 beta 版本到最终发布）更容易接受。在功能冻结前添加功能的冲动也应该会小得多。

根据提议的数字，对错误修复的影响应该很小。相同数量的分支将同时开放进行错误修复维护（两个，直到 2.x 终止，然后是一个）。

新功能的工作流程将保持不变：开发人员只需将它们提交到 default 分支。

错误修复的工作流程将略有更新：开发人员将错误修复提交到当前的 LTS 分支（例如 3.3），然后将其合并到 default 中。

如果非 LTS 版本需要一些关键修复，则可以从当前的 LTS 分支移植到非 LTS 分支，就像今天将修复程序从 3.x 移植到 2.7 一样。

重视稳定性的人们只需同步 LTS 版本，根据提议的数字，这将提供类似的支持周期（持续时间和稳定性方面）。

重视反应性和访问新功能的人们（而不承担安装 alpha 版本或 Mercurial 快照的风险）将从新的发布周期中获得比目前更大的价值。

希望贡献新功能或改进的人们将更有动力这样做，因为他们知道他们的贡献将更快地提供给普通用户。此外，较短的功能冻结期使与功能贡献者互动变得不那么麻烦。

这些是在讨论期间应解决的开放性问题。

在做出最终决定之前，对更广泛的 Python 社区进行社区民意调查或调查将非常有价值。

本文档已置于公共领域。