PostgreSQL 8.4 开发计划

这是 2008 年 2 月 6 日发送到 -hackers 的邮件 的副本，概述了核心团队针对 8.4 开发周期的计划。

---

黑客们,

如你所知，我们终于发布了 PostgreSQL 8.3，尽管我们最初计划为 6 个月的周期，但开发周期却持续了 1 年多。核心团队意识到，导致这种情况的因素有很多。

• 缺乏及时和早期对补丁的审查。
• 提交的补丁数量和复杂性显著增加。
• 优先完成未完成的补丁，而不是按时间表进行。

在 8.4 开发周期中，我们想尝试一种新的开发风格，旨在将补丁队列控制在有限的范围内，并及时向开发人员提供他们提交工作的反馈。为此，我们将用一系列“提交节”取代传统的“功能冻结”。提交节的想法在去年 10 月的 -hackers 中讨论过，似乎得到了普遍认可。每当进行提交节时，重点将从开发转向补丁的审查、反馈和提交。每个提交节将持续到队列中的所有补丁都已提交到 CVS 存储库、退回给作者以进行额外的工作或被完全拒绝，在此之前，不会考虑新的补丁。当然，单个开发人员可以自由地在整个提交节期间继续处理他们的补丁，但我们鼓励每个人尽他们所能帮助处理补丁队列。我们认为，这个想法只有在整个开发社区愿意在提交节期间专注于补丁审查的情况下才能成功，就像每个人都被期望在 beta 期间专注于测试一样。

该周期的拟定时间表如下：

• 2008 年 3 月 1 日 - 提交节开始
• 2008 年 5 月 1 日 - 提交节开始
• 2008 年 7 月 1 日 - 提交节开始
• 2008 年 9 月 1 日 - 提交节开始
• 2008 年 11 月 1 日 - 最终提交节开始
• 2009 年 1 月 1 日 - beta 1
• 2009 年 3 月 1 日 - 8.4.0 发布

注意，这里没有明确的“功能冻结”日期。但是，任何在 11 月 1 日之前没有提交的重大功能补丁显然将无法进入 8.4。

我们希望不会在 10 月底出现大量的、之前未经审查的补丁——如果那样的话，我们将回到 8.3 功能冻结时的相同位置。虽然这个时间表允许最终提交节花费相当长的时间，但我们保留拒绝那些过大而无法及时审查的补丁的权利。我们希望鼓励人们以增量的方式进行大型功能的开发，每个提交节都发布一个新的增量。