摘要

Python 从历史上看只有一个开发分支，发布版本兼具添加新功能和修复错误的目的（此类版本将被称为“主要版本”）。本 PEP 描述了如何分叉旧版本的维护或错误修复版本，其主要目的是修复错误。

本 PEP 并非，重复，并非保证错误修复版本的发布；它仅指定在 Python 社区中有足够多的人愿意进行工作并希望发布错误修复版本时应遵循的流程。

动机

随着迁移到 SourceForge，Python 的开发速度加快了。社区中的一部分人认为速度过快，许多人不愿意升级到新版本以获取错误修复，因为添加了许多功能，有时是在开发周期的后期。

解决此问题的一种方法是维护以前的稳定版本，提供错误修复，直到下一个稳定版本发布。这应该使 Python 对企业开发更有吸引力，因为 Python 可能需要安装在数百或数千台机器上。

禁止事项

错误修复版本需要遵守以下限制

1. 必须零语法更改。所有 .pyc 和 .pyo 文件必须能够工作（无需重新生成）并且适用于从稳定版本分叉的所有错误修复版本。
2. 必须零 pickle 更改。
3. 必须没有不兼容的 C API 更改。所有扩展必须继续工作，无需在稳定版本相同分支的所有错误修复版本中重新编译。

违反任何这些禁止事项都需要 BDFL 发布声明（并在发行说明中发出醒目的警告）。

非严格禁止事项

在可能的情况下，错误修复版本还应

1. 没有新功能。错误修复版本的目的是修复错误，而不是添加来自 CVS 根目录 HEAD 的最新和最棒的功能。
2. 轻松升级。用户应该确信从 2.x.y 升级到 2.x.(y+1) 不会破坏其正在运行的系统。这意味着，除非有必要修复错误，否则标准库不应该更改行为，或者更糟糕的是，更改 API。

禁止事项的适用范围

上述禁止事项和非严格禁止事项既适用于最终版本到错误修复版本的发布（例如，2.4 到 2.4.1），也适用于一个错误修复版本到系列中下一个错误修复版本的发布（例如 2.4.1 到 2.4.2）。

遵循本 PEP 中列出的禁止事项应该有助于让社区确信错误修复版本是一个轻松且安全的升级。

协助错误修复版本的发布

以下是一些关于如何协助错误修复版本发布过程的提示。

1. 回传错误修复。如果您修复了一个错误，并且看起来合适，请将其移植到当前错误修复版本的 CVS 分支。如果您不愿意或无法自己回传它，请在提交消息中添加注释，例如“错误修复候选”或“回传候选”。
2. 如果您不确定，请询问。询问负责当前错误修复版本的负责人，他们是否认为某个特定修复是合适的。
3. 如果您特别希望在错误修复版本中修复某个特定错误，请大声疾呼并尝试完成它。不要等到错误修复版本发布前 48 小时才开始要求包含错误修复。

版本号

从 Python 2.0 开始，所有主要版本都必须具有 X.Y 格式的版本号；错误修复版本始终具有 X.Y.Z 格式。

正在开发的当前主要版本称为版本 N；刚刚发布的主要版本称为 N-1。

在 CVS 中，错误修复版本在分支上进行。对于版本 2.x，分支名为“release2x-maint”。例如，2.3 维护版本的版本分支为 release23-maint

流程

管理错误修复版本的流程部分借鉴了 Tcl 系统 [1]。

补丁负责人是错误修复版本的 BDFL 的对应者。但是，BDFL 和指定的委派人保留对单个补丁的否决权。补丁负责人可能只负责一个开发分支——很可能不同的人维护 2.3.x 和 2.4.x 版本。

随着单个补丁被贡献到 CVS 的当前主干，每个补丁提交者都被要求考虑该补丁是否适合包含在错误修复版本中。如果认为补丁合适，提交者可以将其提交到维护分支，或者在提交消息中标记该补丁。

此外，Python 社区的任何人都可以自由地建议包含补丁。可以专门为错误修复版本提交补丁；它们应遵循 PEP 3 中的指南。不过，总的来说，最好是在 HEAD 和分支上都修复特定版本中的错误。

补丁负责人决定何时有足够的补丁来保证发布。发布版本将被打包，包括 Windows 安装程序，并公开发布。如果发现任何新错误，必须立即修复它们并发布新的错误修复版本（版本号递增）。对于 2.3.x 周期，补丁负责人（Anthony）尝试大约每六个月发布一次，但这不应被视为对任何未来版本具有约束力。

错误修复版本预计以大约六个月的间隔发布。但这只是一项指导原则——显然，如果发现重大错误，则可能需要更早发布错误修复版本。一般来说，任何时候都只对 N-1 版本进行主动维护。也就是说，在 Python 2.4 开发期间，Python 2.3 会获得错误修复版本。但是，如果有人有能力继续维护旧版本的工作，应该鼓励他们这样做。

补丁负责人历史

Anthony Baxter 是 2.3.1 到 2.3.4 的补丁负责人。

Barry Warsaw 是 2.2.3 的补丁负责人。

Guido van Rossum 是 2.2.2 的补丁负责人。

Michael Hudson 是 2.2.1 的补丁负责人。

Anthony Baxter 是 2.1.2 和 2.1.3 的补丁负责人。

Thomas Wouters 是 2.1.1 的补丁负责人。

Moshe Zadka 是 2.0.1 的补丁负责人。

历史

此 PEP 最初是在 comp.lang.python 上提出的。原始版本建议与 N 版本同时发布 N-1 版本的单个补丁。原始版本还主张坚持严格的错误修复策略。

在收到 BDFL 和其他人的反馈后，编写了 PEP 草案，其中包含扩展的错误修复版本周期，允许任何以前的稳定版本获取补丁，并且放宽了严格的错误修复要求（主要是由于 PEP 235 的示例，它可以被认为是错误修复或功能）。

然后讨论主要转移到 python-dev，BDFL 最终发布了一项声明，将 Python 错误修复版本流程建立在 Tcl 的基础上，这基本上在仅为 N-1 版本和仅修复错误方面回到了最初的提议，但允许在发布 N 版本之前进行多次错误修复版本发布。

然后，Anthony Baxter 根据 2.3 发布周期的经验教训修改了此 PEP。

参考文献

版权

本文档已进入公有领域。