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。

按照这些数字，一个新的LTS版本将每24个月发布一次，并在接下来的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社区的意见将很有价值。

本文档已置于公共领域。