更新版本发布草稿
发布更新版本草稿
这是一套关于为 PostgreSQL 编写更新版本 (次要版本) 公告草稿的指南。
更新版本分为两种类型：累积修复版本和安全版本。它们的区别在于版本中是否修复了 CVE 级别的安全漏洞。根据情况不同，更新版本公告草稿的编写流程也不同。为了确定要准备哪种类型的版本，你需要在更新版本发布前大约两周向 PostgreSQL 安全团队成员咨询。
更新版本通常在周四发布，压缩包在周一打包。本指南的其余部分假设这是发布日程。
累积修复版本
这些是修复了一些问题但没有出现严重到需要 CVE 的安全问题的次要版本。通常情况下，它们发布的原因是： (a) 我们修复了一个数据损坏或严重崩溃的错误，或者 (b) 我们在没有任何其他事情发生的情况下积累了 3 个月的错误修复。以下是编写此类版本草稿的步骤。
时间安排
发布前一到两周
你需要了解该版本中的主要修复。
- 确定该版本中修复的任何问题是否紧急，例如严重的数据损坏错误。
- 确定更新中是否有任何更改需要用户采取行动或特殊解释，例如向后兼容性问题。
- 确定发布中是否有特殊公告需要包含，例如旧版本的 EOL。
确定了以上内容后，你可以开始编写发布草稿 (见下文)。
发布前周五
- 完成草稿，除了修复的杂项问题列表之外。
- 通知区域联系人即将发布更新版本，以及将要修复的任何主要问题。
发布周周一 (美国时间)
一旦更新版本分支出来，检查发布说明和 Git 提交列表，以便为该版本组装一个“其他错误修复”列表。完成发布草稿。向 Hackers 发送发布草稿的链接，以便让大家检查你对修复列表的描述和相关性。
周二晚上或周三早上 (美国时间)
- 结合 Hackers 的反馈意见。
- 根据 MD 发布草稿制作一个 TXT 版本。
- 检查并告知 Magnus Hagander 和 Dave Page 它已完成。
- 向区域联系人发送最终版本。
周四早上
Magnus 或 Dave 将发布该版本。
发布后
将公告移到 /archive/ 目录下。
发布草稿
更新版本应基于 git.postgresql.org/press 存储库中的“更新版本模板”。参与发布的贡献者应在 update_releases/current/ 子目录中创建文件，并在该目录中进行协作。分支或分叉的策略由参与的贡献者决定。
每个版本都会生成两个文件：一个 Markdown 文件，用于网站上的新闻部分，以及一个文本版本，用于电子邮件发送。通常情况下，最简单的方法是在 Markdown 版本上工作，并在 Markdown 版本最终确定后将其转换为文本版本。
发布的紧急程度
我们使用特定的语言来描述用户需要多快应用该版本。如下所示。
强烈建议受影响版本的所有用户立即应用更新：该版本包含一个高风险的安全漏洞或影响所有用户的严重数据丢失错误。停止阅读，宣布停机，并立即应用更新。幸运的是，在过去 6 年中我们只遇到过一次这种情况。
所有用户应尽快应用此更新：该版本包含一个或多个安全漏洞和/或预计会影响大多数用户的重大数据丢失错误。今晚或本周末安排停机时间，并应用更新。
所有 _________ 用户应立即/尽快应用此更新：与上述相同，但仅针对特定功能或扩展的使用者。
用户应在下次可用机会应用此更新：该版本包含一些低风险的安全漏洞和/或仅在特定情况下才会发生的严重数据丢失错误。更新到此版本不应推迟超过几周，但你可以等待低流量时段来停机。
用户应在下次定期维护窗口/计划停机时间更新：此更新对于大多数用户来说并不关键或严重，它主要是对错误修复的累积收集。该更新应添加到生产服务器的通用操作系统、库和应用程序更新队列中。
重要修复
一些，但并非所有错误修复版本都修复了一个或多个主要问题，并建议为用户提供更详细的说明。具体来说
- 主要数据损坏问题
- 破坏向后兼容性的修复
- 需要更新后用户操作的修复
错误修复列表
几乎每个版本都包含一个杂项错误修复列表，这些修复是在过去几个月内积累的。这应该是一个包含稳定分支提交的 40% 到 70% 修复的列表。你应该在这个列表中包含具有用户可见影响的重大错误，尤其是那些最初受影响的用户应该测试的错误。你通常还需要缩短这些问题的摘要行，以便它们能在一行内显示。查看之前的更新版本以获取示例。
EOL 通知
我们会在版本达到 EOL 之前发出至少两次通知：一次是在达到 EOL 之前，让用户知道下一次更新将是最后一次更新，另一次是在达到 EOL 时，让用户知道这是该版本最后一次更新。
安全版本
安全版本是包含了一个或多个足以获得 CVE 的安全问题的修复的版本。
由于存在这些安全修复信息，我们无法使用公共流程来编写发布草稿。
除此之外，创建安全版本的流程与创建常规更新版本的流程基本相同。以下是不同的部分，其他部分请参考上面的更新版本。
模板
使用 安全版本 模板。
选择发布作者
发布前两周，发布委员会将征求两名作者来编写发布草稿。
- 宣传组的公关作者
- 安全组的安全专家
公关作者需要是公认的谨慎的社区成员，但不需要是安全团队成员。
发布前一到两周
安全团队成员将与公关作者联系，告知修复的安全版本的相关说明。公关作者将与安全团队成员一起，简明准确地总结这些问题。这项工作将通过电子邮件和/或安全、私人的协作机制完成 (但不会通过 git.postgresql.org)。
与常规更新版本不同，公关作者不能在 pgsql-hackers 上分享发布草稿的完整文本，以查找更多有关包含的补丁的信息。相反，他们只应分享补丁列表，不包括任何安全补丁。
发布前周五
你可以通知区域联系人即将发布一个版本，但不要透露内容。
发布前三天 (周一)
此时，安全版本的修复应该已提交到 Git，并且我们应该拥有 CVE 的最终文本。
- 安全团队成员将与公关作者分享 CVE 编号和文本。
- 公关作者可以最终确定文本，并将其发布草稿检查到 git.postgresql.org/press 中。
- 公关作者将为网站创建一个补丁，用于更新 安全页面
- 公关作者可以与区域联系人分享发布草稿。
安全页面上的补丁应该以现有格式列出所有 CVE 及其关联信息。此补丁将提交给 Web 团队进行审核，并提交给安全团队成员以检查安全信息。
后续
发布后一周，如果 PostgreSQL 的某个版本现在已达到 EOL，公关作者应创建一个补丁，将仅与 EOL 版本相关的安全问题移动到 安全存档页面。
