摘要

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

发布计划

未来版本发布日期（暂定）

[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

已了解任何贡献的代码都将根据开源许可证发布。如果无法以这种方式发布代码，请勿贡献代码。