PostgreSQL 版本发布节奏

PostgreSQL 遵循极具预测性的版本发布节奏：每年发布一个包含新功能的主要版本（通常在第三季度末或第四季度初，如 9 月或 10 月），并每季度发布一次小版本（即修复漏洞和安全漏洞的补丁，通常在 2 月、5 月、8 月、11 月的第二周）。

PostgreSQL 社区以其极其稳定和可预测的发布节奏而闻名。了解这一节奏，可用帮助数据库管理员（DBA）和开发团队规划升级、维护和生命周期管理。

以下是 PostgreSQL 版本发布节奏的详细说明：

大版本发布 (Major Releases)

大版本通常包含新的功能、架构更改以及可能的向后不兼容更改，需要数据升级。

• 发布频率： 每年一次。
• 发布时间： 通常在第三季度末或第四季度初（9月或 10月）。
• 版本号规则：
  • 从版本 10 开始：第一个数字表示主版本（例如：14, 15, 16）。
  • 版本 10 之前：前两个数字表示主版本（例如：9.5, 9.6）。
• 升级方式： 需要使用 pg_dump/pg_restore 或 pg_upgrade 工具进行数据迁移。数据文件格式通常会发生变化。

小版本发布 (Minor Releases)

小版本主要用于修复 Bug 和安全漏洞（CVE），不包含新功能，旨在保持生产环境的稳定。

• 发布频率： 每季度一次（约每 3 个月，通常是 2月、5月、8月和 11月的第二个周四）。
• 例外情况： 如果发现严重的紧急安全漏洞或数据损坏 Bug，社区会在常规计划外发布紧急小版本。
• 版本号规则：
  • 从版本 10 开始：第二个数字（例如：15.1, 15.2）。
  • 版本 10 之前：第三个数字（例如：9.6.1, 9.6.2）。
• 升级方式： 二进制兼容。只需要安装新二进制文件并重启数据库服务即可，不需要转储/恢复数据。

重要提示： 社区强烈建议用户始终运行当前主版本的最新小版本（例如，如果你在使用 PG 15，应尽快升级到最新的 15.x）。

年度开发与发布时间表

PostgreSQL 的开发周期非常严谨，通常遵循以下年度流程：

1. 提交阶段 (Commitfests) [全年]：

   开发周期被划分为多个“Commitfests”，通常每两个月一次。这是新功能代码提交和同行评审的窗口。

2. 功能冻结 (Feature Freeze) [5 月 / 6 月]：

   通常在每年的 5 月左右，最后一个 Commitfest 结束，不再接受针对下一个大版本的新功能。

3. Beta 测试版 [5月 - 8月]：

   社区开始发布 Beta 版本（Beta 1, Beta 2…）。鼓励用户进行测试，但不建议用于生产环境。

4. 候选发布版 (Release Candidate, RC) [8 月 / 9 月]：

   当代码被认为足够稳定时，发布 RC 版本。如果没有发现重大 Bug，正式版将紧随其后。

5. 正式发布 (GA) [9 月 / 10 月]：

   新的大版本正式向全球发布。

生命周期与停止支持 (EOL)

了解版本何时停止支持（End of Life），可用帮助企业规划版本升级。

• 支持时长： 每个大版本自首次发布起，享有 5 年的支持期。
• 支持内容： 在这 5 年内，该版本会定期获得包含 Bug 修复和安全补丁的小版本更新。
• 停止支持： 5 年后，该版本将不再获得任何更新（包括安全补丁）。通常最后一版会在当年的 11 月发布。

当前版本状态示例（截至 2026 年初）：

总结

PostgreSQL 的发布策略是为了平衡创新（年度大版本）与稳定性（季度小版本）。这种稳定的节奏使得 PostgreSQL 成为业界公认的、兼具创新与企业级稳定性的数据库系统。

如果你是开发者：每年秋季请关注新功能发布（如 JSON 增强、性能优化）。

如果你是运维/DBA：请订阅发布邮件列表，每季度安排一次小版本补丁更新，并每 3-4 年规划一次大版本升级以避免 EOL 风险。

参考

PostgreSQL 社区：版本控制策略 (Versioning Policy)