摘要

本文档描述了 Python 2.0 之后的开发和发布时间表。根据此时间表，Python 2.1 将于2001年4月发布。该时间表主要关注 PEP 级别的事项。小的 bug 修复和更改将在第一个 Beta 版本发布之前进行。

发布时间表

暂定未来发布日期

[bug 修复发布日期在此处]

过去的发布日期

• 2001年4月17日：2.1 最终版本
• 2001年4月15日：2.1 发布候选版 2
• 2001年4月13日：2.1 发布候选版 1
• 2001年3月23日：Python 2.1 beta 2 发布
• 2001年3月2日：第一个 2.1 beta 版本发布
• 2001年2月2日：Python 2.1 alpha 2 发布
• 2001年1月22日：Python 2.1 alpha 1 发布
• 2000年10月16日：Python 2.0 最终版本

Python 2.0 beta 2 的未解决问题

将默认的单元测试框架添加到标准库中。

Python 2.1 变更指南

指南和时间表将根据 python-dev@python.org 邮件列表中的讨论进行修订。

PEP 系统是在 Python 2.0 开发周期的后期才建立的，许多更改并未遵循 PEP 1 中描述的流程。然而，2.1 的开发流程将遵循已记录的 PEP 流程。

2.0 最终版本发布后的前八周将是设计和审查阶段。在此阶段结束时，任何提议用于 2.1 的 PEP 都应准备好进行审查。这意味着 PEP 已撰写完毕，并且已在 python-dev@python.org 和 python-list@python.org 邮件列表中进行了讨论。

接下来的六周将用于审查 PEP、实现和测试已接受的 PEP。当此阶段结束时，我们将停止考虑任何未完成的 PEP。在此阶段接近尾声时，将进行一次功能冻结，届时任何不值得 PEP 的小功能将不被接受。

在最终发布之前，我们将有六周的 Beta 测试以及一到两个发布候选版。

提交补丁和进行更改的一般指南

提交更改时请运用常识。你应该知道我们所说的常识是什么意思，否则我们不会授予你提交权限 <0.5 眨眼>。常识的一些具体例子包括：

• 听从独裁者的指示。
• 首先在 python-dev 上讨论任何有争议的更改。如果你获得了大量 +1 票而没有 -1 票，则进行更改。如果你获得了一些 -1 票，请三思；考虑询问 Guido 的看法。
• 如果更改是你贡献的代码，那么你来修复它可能是有意义的。
• 如果更改影响了其他人编写的代码，那么先征求他或她的意见可能是有意义的。
• 你可以使用 SourceForge (SF) 补丁管理器提交补丁并将其分配给某人进行审查。

任何重要的新功能都必须在签入之前在 PEP 中描述并获得批准。

任何重要的代码添加，例如新模块或大型补丁，都必须包含回归测试和文档的测试用例。在测试和文档准备就绪之前，补丁不应签入。

如果你修复了一个 bug，你应该编写一个能够捕获该 bug 的测试用例。

如果你从 SF 补丁管理器提交补丁或从 Jitterbug 数据库修复 bug，请务必在 CVS 日志消息中引用补丁/bug 编号。此外，请务必更改补丁管理器或 bug 数据库中的状态（如果你有权访问 bug 数据库）。

任何已签入的代码导致回归测试失败都是不可接受的。如果签入导致失败，必须在 24 小时内修复，否则将被回滚。

所有贡献的 C 代码必须是 ANSI C。如果可能，请使用两个不同的编译器进行检查，例如 gcc 和 MSVC。

所有贡献的 Python 代码必须遵循 Guido 的 Python 风格指南。 https://pythonlang.cn/doc/essays/styleguide.html

据理解，所有贡献的代码都将以开源许可证发布。如果无法以这种方式发布，请勿贡献代码。