Go Wiki：Go 发布周期

此维基页面由 Go 团队维护。请 向 golang-dev 发送评论 或 提交问题，而不是直接进行更改。

短链接：https://golang.ac.cn/s/release.

概述

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

在某个版本的初始发布之后，会通过次要版本进行支持，这些次要版本修复了严重的错误和安全问题。

时间线

当前的发布周期与每年 1 月中旬和 7 月中旬开始保持一致。发布周期的目标里程碑如下所述。我们努力尽可能地按目标进行，同时仍能提供高质量的版本。

为了让团队有时间准备并解决意外问题，我们更倾向于在工作周的早期或中期进行发布工作。这意味着具体日期会因年份而异，因此里程碑被指定为特定月份的周数。第 1 周是从该月的第一个星期一开始的周。所有日期均可能根据当年的节假日时间调整。

1 月 / 7 月第 1 周：开始进行发布计划。

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

示例：Go 1.20

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

一旦上一个版本进入其最终稳定阶段，树木就会开放进行一般性开发。在此期间，欢迎进行各种开发。对于大型或风险特别大的更改，最好在开发窗口结束之前很久就完成，以便有时间修复因这些更改而产生的任何问题。

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

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

在冻结期间，只接受错误修复、仅测试更改和文档更新。有时，在冻结期间可能会进行新的工作，但只有在特殊情况下，并且通常只有在该工作在截止日期之前提出并获得批准的情况下才会进行。此类更改必须风险较低。请参阅下面关于 冻结例外 的内容。

发布周期的这一部分专注于通过测试发布版并修复发现的错误来提高发布版的质量。但是，必须对每个修复进行评估，以权衡潜在修复的好处与现在在发布版中拥有未经充分测试的代码（修复）的成本。在发布周期的早期，倾向于接受修复。在发布周期的后期，倾向于拒绝修复，除非可以证明该修复既风险低又回报高。

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

在冻结开始后不久，几乎所有已知的错误都应该已修复或明确推迟（推迟到下一个版本或无限期推迟）。其余的通常应跟踪为发布阻碍因素，并紧急处理。

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

发布候选版本旨在尽可能接近实际发布的比特。发布候选版本意味着 Go 团队对树木没有严重错误抱有高度信心。特别是，由于 Google 持续跟踪 Go 的开发版本，因此在发布候选版本发布时，其近似版本已经在 Google 的生产环境中运行了至少一两个星期。

发布候选版本发布后，只应进行文档更改和解决严重错误的更改。一般而言，此时进行错误修复的门槛甚至比次要版本中的错误修复门槛还要高。我们可能更倾向于发布一个存在已知但非常罕见的崩溃的版本，而不是发布一个包含新的但未经生产测试的修复的版本。

如果报告并修复了严重错误，则可能会发布额外的发布候选版本，但通常每两周不超过一次。

同样，发布候选版本旨在尽可能地没有错误。鼓励组织在进行适当的组织特定测试后将其部署到生产环境中。

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

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

在当前版本稳定时，树木会重新开放以进行下一个版本的开发工作。在此期间，针对当前版本的修复需要 移植到发布分支。与次要版本的移植不同，这些更改不需要移植问题，也不需要由发布团队批准。只要它们符合 冻结策略，它们就可以像其他任何 CL 一样进行审查和提交。

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

最后，发布版本本身！

发布版本不应包含自上一个发布候选版本以来的重大更改：重要的是发布版中的所有代码都已经过充分测试。发布版本意味着发布测试已确认发布候选版本对树木没有严重错误抱有高度信心。

即使发布顺利且有空闲时间，我们也更倾向于按计划进行。额外的测试只会提高发布版的稳定性，它也让从事 Go 版本开发的开发者有更多时间在代码更改开始涌入之前思考和计划下一个版本。

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

一旦某个版本稳定，下一个版本的开发工作（包括代码审查和新代码提交）就可以开始了，并且循环重复。请注意，如果发布延期，下一个版本的开发工作也可能延期。

版本维护

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

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

另请参阅 MinorReleases 维基页面。

冻结例外

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

对冻结的任何例外情况必须在冻结之前通知 Go 发布团队并获得他们的明确批准。如果您想申请例外，请在问题跟踪器中提交一个问题，并在问题后缀中添加“[冻结例外]”，并包含“CC @golang/release”（示例）。我们将根据具体情况处理所有请求，并且非常不愿意在冻结后允许更改。

历史记录

此时间表的某个版本最初是在 2016 年针对 Go 1.7 版本采用，其中开发窗口较短。在 2022 年和 2023 年进行了多年的发布、测试和流程改进，导致 1.19 版本及时发布。对于 1.20 版本，开发窗口扩展了，冻结时间较晚，解冻时间较早。这些更改已在 1.21 版本中正式化。我们预计将继续按时发布。

此内容是 Go Wiki 的一部分。