摘要

Python 在历史上只有一次分叉开发，其发布的目的是增加新功能和提供漏洞修复（这些类型的发布将被称为 “主要发布”）。这个 PEP 描述了如何将旧版本的维护或漏洞修复分叉出来，主要目的是修复漏洞。

这个 PEP 不是，重复一遍，不是对错误修复版本存在的保证；它只是指定了一个程序，在有足够多的 Python 社区愿意做这项工作的情况下，需要遵循这个程序。

动机

随着向 SourceForge 的转移，Python 的发展已经加速。在社区的一部分人中有一种情绪，认为加速的程度太高了，在增加了这么多功能的情况下，许多人对升级到新版本以获得错误修复感到不舒服，有时在开发周期的晚期。

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

禁止事项

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

1. 必须有零的语法变化。所有的 “.pyc” 和 “.pyo” 文件必须能与所有从主要版本分叉出来的错误修正版本一起工作（不需要再生）。
2. 必须有零的 pickle 变化。
3. 不能有任何不兼容的C语言API变化。在与主要版本相同的分叉中的所有错误修复版本中，所有扩展必须继续工作而不需要重新编译。

违反任何这些禁令都需要 BDFL 的公告（以及在发布说明中的显著警告）。

不完全禁止

在可能的情况下，错误修复版本也应如此：

1. 没有新的功能。错误修复版本的目的是修复错误，而不是从 CVS 根的 HEAD 中添加最新、最棒的 whizzo 功能。
2. 成为一个无痛的升级。用户应该感到有信心，从 2.x.y 升级到 2.x.(y+1) 不会破坏他们的运行系统。这意味着，除非有必要修复一个错误，否则标准库不应该改变行为，或者更糟糕的是，不应该改变 API。

禁止事项的适用性

上述禁令和不完全禁令既适用于一个最终版本到一个错误修复版本（例如，2.4 到 2.4.1），也适用于一个系列中的一个错误修复版本到下一个系列（例如 2.4.1 到 2.4.2）。

遵循本 PEP 中列出的禁令应该有助于保持社区的快乐，即错误修复版本是一种无痛和安全的升级。

有助于错误修复的发布

这里有一些关于帮助错误修复发布过程的提示。

1. 回传错误修复。如果你修复了一个bug，而且看起来很合适，就把它移植到当前 bug 修复版本的 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 维护版本的分支是 release23-maint

流程

管理 bugfix 发布的过程部分仿照了 Tcl 系统 [1]。

Patch Czar 是与 BDFL 相对应的，用于错误修复发布。然而，BDFL 和指定的任命者对单个补丁保留否决权。一个补丁管理员可能只负责一个开发分支–很可能一个不同的人在维护 2.3.x 和 2.4.x 版本。

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

In addition, anyone from the Python community is free to suggest patches for inclusion. Patches may be submitted specifically for bugfix releases; they should follow the guidelines in PEP 3. In general, though, it’s probably better that a bug in a specific release also be fixed on the HEAD as well as the branch.

补丁管理员决定何时有足够数量的补丁需要发布。该版本被打包，包括一个 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-1 版本打一个补丁，与 N 版本同时发布。最初的版本还主张坚持严格的错误修复政策。

Following feedback from the BDFL and others, the draft PEP was written containing an expanded bugfix release cycle that permitted any previous major release to obtain patches and also relaxed the strict bug fix requirement (mainly due to the example of PEP 235, which could be argued as either a bug fix or a feature).

后来讨论主要转移到 python-dev，在那里BDFL终于发布了一个公告，将 Python 的 bugfix 发布过程建立在 Tcl 的基础上，这基本上回到了最初的提议，即只做 N-1 版本，只做 bugfix，但在 N 版本发布之前允许多次 bugfix 发布。

Anthony Baxter 随后根据 2.3 发布周期的经验教训，对这个 PEP 进行了修订。

参考

版权声明

本文档已被置于公共领域。