摘要

Python 历史上只有一个开发分支，发布的目的是同时增加新功能和提供错误修复（这些类型的发布将被称为“主要版本”）。本 PEP 描述了如何从旧版本中分离出维护或错误修复版本，其主要目的是修复错误。

本 PEP 并非，重复并非，保证错误修复版本的存在；它只规定了如果足够多的 Python 社区愿意承担这项工作，并且需要错误修复版本时应遵循的程序。

动机

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

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

禁止事项

Bug 修复版本必须遵守以下限制

1. 语法必须零更改。所有 .pyc 和 .pyo 文件必须与从主要版本派生出来的所有 bugfix 版本兼容（无需重新生成）。
2. Pickle 必须零更改。
3. 不得有不兼容的 C API 更改。所有扩展必须在与主要版本在同一分支中的所有 bugfix 版本中继续工作，无需重新编译。

违反任何这些禁令都需要 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 中列出的禁止事项有助于让社区满意，认为错误修复版本是无痛且安全的升级。

帮助实现 Bug 修复版本

以下是一些帮助错误修复版本过程的提示。

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

版本号

从 Python 2.0 开始，所有主要版本都要求版本号为 X.Y 形式；错误修复版本将始终为 X.Y.Z 形式。

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

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

流程

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

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

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

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

补丁负责人决定何时有足够的补丁来发布。发布会被打包，包括一个 Windows 安装程序，并公开发布。如果发现任何新的 bug，必须立即修复并公开发布一个新的 bugfix 版本（版本号递增）。对于 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-1 版本发布一个与 N 版本同时发布的单一补丁。最初的版本还主张坚持严格的错误修复策略。

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

讨论随后主要转向 python-dev，BDFL 最终发布了一项公告，将 Python 的 bugfix 发布流程基于 Tcl 的流程，这本质上又回到了最初的提案，即只针对 N-1 版本且只进行 bug 修复，但允许在 N 版本发布之前进行多次 bugfix 发布。

Anthony Baxter 随后根据 2.3 发布周期的经验教训，修订了本 PEP。

参考资料

版权

本文档已置于公共领域。