Go Wiki: Go-Release-Cycle

本 Wiki 页面由 Go 团队维护。请 发送评论到 golang-dev 或 提交 issue，而不是直接进行更改。

短链接：https://go-lang.org.cn/s/release。

概览

Go 每六个月发布一次。每个发布周期分为大约 4 个月的开发阶段，然后是 3 个月的测试和完善期，称为发布冻结期。如果一切顺利，在上一版本发布之前就会开始下一版本的开发工作，从而导致大约一个月的重叠期。

版本初始发布后，将通过修复严重 bug 和安全问题的次要版本进行支持。

时间线

当前的发布周期安排在每年 1 月中旬和 7 月中旬开始。发布周期的目标里程碑如下所述。我们尽量贴近目标，同时仍交付高质量的版本。

为了给团队留出准备时间和处理意外问题，我们倾向于在周中或周中早期进行发布工作。这意味着具体日期每年都会有所不同，因此里程碑是按特定月份的周来指定的。第 1 周是指从当月第一个星期一开始的那一周。所有日期都可能根据当年的假期安排而变化。

1 月/7 月第 1 周：开始发布规划。

即将到来的发布周期的主要工作规划将在 golang-dev 上宣布。

示例：Go 1.20

1 月/7 月第 3 周：开始发布工作。

在上一版本进入最终稳定期后，代码树将对通用开发开放。在此期间欢迎各种开发。最好是大型或特别有风险的更改在开发窗口结束前较早合并，以便有时间修复随之出现的问题。

5 月/11 月第 4 周：开始发布冻结。

此里程碑标志着发布周期的第二部分，即发布冻结。发布冻结适用于整个主存储库以及构建发布中所包含的二进制文件所需的子存储库中的代码，特别是 vet 及其在 tools 子存储库中的所有依赖项。

在此冻结期间，只接受 bug 修复、仅测试更改和文档更新。偶尔也可能在冻结期间进行新的工作，但仅限于特殊情况，并且通常仅当工作在截止日期之前已提出并获得批准的情况下。此类更改必须风险较低。请参阅下面的 冻结例外。

发布周期的这一部分专注于通过测试和修复发现的 bug 来提高版本的质量。但是，必须评估每个修复，以权衡潜在修复的好处与将未经充分测试的代码（即修复）纳入发布的成本。在发布周期的早期，倾向于接受修复。在发布周期的后期，倾向于拒绝修复，除非能够证明该修复的风险低且回报高。

在周期后期适合进行的低风险更改的示例包括对文档的更改以及对当前版本中引入的新功能的修复（因为不会出现与早期版本相比的回归）。

冻结开始后不久，几乎所有已知 bug 都应已修复或明确推迟（推迟到下一个版本或无限期推迟）。剩余的 bug 通常应被跟踪为发布阻塞项并紧急处理。

6 月/12 月第 2 周：发布候选版 1 发布。

发布候选版旨在尽可能接近最终发布版本。发布候选版的发布表明 Go 团队对代码树没有关键 bug 抱有高度信心。特别是，由于 Google 会持续跟踪 Go 的开发版本，因此在发布候选版发布时，其近似版本至少已在 Google 的生产环境中运行了一到两周。

发布候选版发布后，只应进行文档更改和修复关键 bug 的更改。总的来说，此时 bug 修复的标准比次要版本中的 bug 修复标准还要高。我们可能宁愿发布一个已知但很少见的崩溃版本，也不愿发布一个包含新但未经生产环境测试的修复的版本。

如果报告并修复了关键 bug，可能会发布其他发布候选版，但通常每两周不超过一个。

再次强调，发布候选版应尽可能做到无 bug。鼓励组织在经过适当的组织特定测试后将其部署到生产环境。

发布候选版与最终发布之间的平静期是进行额外测试或讨论下一个版本（请参阅上面的规划里程碑）的好时机。

7 月/1 月第 3 周：开始下一版本的工作

在当前版本稳定化的同时，下一版本的工作也将开始。在此期间，旨在用于当前版本的修复需要 挑选到发布分支。与次要版本的挑选不同，这些更改不需要 backport issue，也不需要发布团队批准。只要它们符合 冻结策略，就可以像任何其他 CL 一样进行审核和提交。

8 月/2 月第 2 周：发布。

最终，发布本身！

发布不应包含自上次发布候选版以来的重大更改：所有发布代码都经过充分测试这一点很重要。发布标志着发布测试已确认发布候选版对代码树没有关键 bug 抱有高度信心。

即使发布顺利且有空余时间，我们也倾向于按计划进行。额外的测试只能提高版本的稳定性，并且还能让负责 Go 版本开发的开发人员在代码更改再次涌入之前，有更多时间思考和规划下一个版本。

到最终发布时，Google 将已使用此版本的 Go 近两个月。虽然 Google 的成功使用并不保证没有问题，但我们的经验表明，它确实有助于提高版本的质量。我们强烈鼓励其他组织尽可能积极地测试发布候选版，并报告发现的问题。

一旦版本稳定下来，就可以开始下一版本的工作，包括代码审查和新代码的提交，然后循环重复。请注意，如果发布延迟，下一版本的工作也可能延迟。

版本维护

发布次要版本是为了解决一个或多个没有变通方法（通常与稳定性和安全性相关）的严重问题。版本中包含的唯一代码更改是针对特定严重问题的修复。重要的仅文档更改和安全的测试更新（例如禁用测试）也可能包含在内，但仅此而已。次要版本尽可能保留向后兼容性，并且不引入新 API。

针对 Go 1.x 的问题（包括安全问题）的次要版本发布，将在 Go 1.x+2 版本发布后停止。有关安全更新的更多信息，请参阅 安全策略。

另请参阅 MinorReleases Wiki 页面。

冻结例外

符合 冻结策略 的修复 CL 不需要冻结例外。

冻结的任何例外情况必须在冻结之前与 Go 发布团队沟通并获得明确批准。如果您想请求例外，请在 issue tracker 中提交一个 issue，并在后面加上“[freeze exception]”后缀，并包含“CC @golang/release”（示例）。我们将逐个处理任何请求，并强烈倾向于不允许在冻结后进行更改。

历史说明

此计划的一个版本，开发窗口较短，最初于 2016 年为 Go 1.7 发布采用。经过多年的艰难发布，2022 年和 2023 年的测试和流程改进促成了及时的 1.19 发布。对于 1.20，通过延迟冻结和提前解冻来扩展了开发窗口。这些更改已正式化用于 1.21 发布。我们预计将继续按时发布。