背景

作为一个 Gopher 有必要了解一下 Go 语言的发布计划。

Go 团队已经有相关 wiki 文档对此做了详细的阐述。

https://github.com/golang/go/wiki/Go-Release-Cycle 最后更新于:Jan 19, 2019, 10:58 AM GMT+8

概述

在过去的 Go 1.0 和 Go 1.1 的 14 个月中,Go 团队采用了发布时间表来简化工作,完成和发布的过程。

总体目标是每6个月发布一次主要版本,然后细分为3个月的常规开发,然后是3个月的测试和优化,即所谓的版本冻结。

通过发行小版本来纠正诸如崩溃或安全性等关键问题。

需要大家特别注意的是,此页面记录了我们打算为即将发布的版本所做的工作。如果你熟悉我们过去所做的工作,请特别注意“历史”部分中描述的差异。

时间线

当前的发布周期定于每年的2月1日和8月1日。 发行周期的目标里程碑如下所述。我们尽力达到目标,同时仍提供高质量的版本。

Beta, 发行候选版和发行版本通常是去确定在周中,通常是在星期三。我们避免在星期一或星期五,以免因为发布遇到意外的问题而加班。

1月15日/7月15日:开始计划发布

golang-dev 中宣布即将发布的主要工作计划。

例如:

2月1日/8月1日:开始准备发布

如果之前的版本尚未发布,则此里程碑将会被延迟,但是请注意,后面的里程碑不会被延迟。也就是说,未能按时发布一个发行版将花费大量时间,而不是后续发行版的开发周期。

请注意,应在正常发行工作期间处理传入的错误报告并修复错误。不宜将所有错误修复都保留为发行版冻结。在“历史”部分,有更多的讨论。

5月1日/11月1日:开始冻结发行版本

这个里程碑开始了发布周期的后半部分,即发布冻结。版本冻结适用于整个主存储库以及构建该版本中包含的二进制文件所需的子存储库中的代码,尤其是 godoc 及其在工具子存储库中的所有依赖项。

在冻结之前提交的更改,可以在冻结开始后立即进行检查。在冻结期间,只接受 bugfix 和文档更新。有时,在冻结期间可能完成了一些新的工作,但是只有在特殊情况下,通常只有在截止日期之前提出并批准了的工作,才能进行新工作。此类更改必须是低风险的。

发布周期的这一部分专注于通过测试和修复发现的错误来提高发布质量。但是,必须对每个修复程序进行评估,以平衡可能的修补程序的收益与现在版本中未经过良好测试的代码的成本。在发布周期的早期,平衡趋向于接受修复程序。在发布周期的后期,除非有理由证明修复程序既低风险又有高回报,否则平衡趋向于拒绝修复程序。

在周期的后期进行的低风险更改示例包括对文档的更改以及对当前版本中引入的新功能的修复。(因为与早期版本相比,没有机会引入回归)。

在冻结的第一个月月底之前,几乎所有已知的错误都应该已经得到修复或者明确推迟(要么推迟到下一个版本,要么无限期推迟)。应该只剩下很少的已知错误,也许只有那些已经证明难以捉摸的错误才可以解决。

6月1日/12月1日:发布 Beta1

Beta 版本旨在鼓励测试以发现新的错误。发行 Beta 版本表明 Go 团队已经修复了几乎所有已知的 bug 了,现在是时候去寻找未知的 bug 了。

第一个 Beta 版包含最终发行说明的完整草稿,但为了避免人们在互联网上链接到这些草稿时产生混淆,它被明确的标记为草稿。

如果一个版本比计划提前了,它是可以接受的,甚至鼓励提前几周发布一个测试版。

报告并修复了错误后,如果有大量代码更改需要重新测试,则可能会发布其他beta。 通常,测试版的发布时间不应超过两周。 重要的是,不要发布过多的beta版本,也不要发布太多的候选版本:我们要求用户花些时间来帮助我们测试发布,并且切勿因提出过多请求而浪费其诚意。

beta版不应该是没有 bug 的,也不应该用于不能容忍故障或不当行为的生产环境中。组织可以针对测试版运行集成或其他测试,甚至在金丝雀环境中使用它,但是不应该将测试版部署到不受限制的生产环境中。

7月1日/1月1日:发布候选版本1

候选发行版应尽可能接近实际发行版。发行候选版表明 Go 团队非常确信没有严重的 bug。

一旦发布了候选版本,就应该只对文档进行修改,并对严重 bug 进行修改。一般来说,此时的 bug 修复标准甚至比小版本中的 bug 媳妇标准稍高。我们可能更喜欢发布一个已知但很少发生的崩溃的版本,而不是发布一个新的但没有经过生产测试的修复的版本。

如果一个版本比计划提前了,它是可以接受的,深圳鼓励提前几周发布一个候选版本。扩展发行版测试是交付强大发行版的好方法。

如果报告并修复了严重的 bug,则可以发布其他候选版本,但通常不会超过每两周发布一次。

同样,发行候选版本应尽可能的没有错误。鼓励组织在适当的组织特定测试之后在生产环境中使用。

发行候选版本的标准之一是 Google 默认将该版本的代码用于新的生产版本:如果 Google 不想将其用于生产环境,我们就不应要求其他人使用。我们可能会在 Google 改变之前几天发布候选版本,这取决于日历日期。例如,在星期一 进行 Google 内部更改更有意义,因此默认情况下,我们可以在 Google 变更为新版之前的星期三或之后的星期三发布候选版本。

候选发行版和最终发行版之间的平静日期是进行额外测试或讨论下一个发行版的好时机。(参考上面1月15日的里程碑)

8月1日/2月1日:发布版本

自上一个候选版本以来,一个版本不应包含重大变更:重要的是,必须对该版本中的所有代码进行充分测试。发行版本表明发行测试已经确认了候选发布者对于没有严重错误的高度信心。

发布版本的标准之一是,候选版本已经用了4周,并且已经解决了任何需要解决的问题。

如果发布进程提前了,并且有一个早期的 Beta 版本和早期的候选版本,那么候选版本测试应该占用这些额外的时间,而不要过早的保留实际发布时间。这提高了发行版的稳定性,同时也给 Go 开发人员更多的时间来思考和计划下一个发行版,而不是又陷入开发中。

如果发布进程落后于计划,可以在发布候选版本后的4周之前发布一个版本是可以接受的(但肯定不是理想的),但在发布候选版本的两周之前发布一个版本是不可取的。简短的发布测试是交付有缺陷的版本的根本原因。

因为 Google 将候选发布版本作为 Go 的默认版本运行,因此4周的发布测试意味着 Google 至少使用了4周正式版本了。尽管 Google 的成功使用不能保证没有问题,但我们的经验是,它肯定有助于提高发行版的质量。我们强烈鼓励其他组织尽可能积极的测试候选发布版本,并报告发现的问题。

发布版本后,就可以开始下一个版本的工作,包括代码审查和新代码的提交,并且重复该循环。请注意,如果某个版本被延迟,那么下一个版本的工作也会延迟。

维护发布版本

发布一个小版本是为了解决一个或多个没有解决方案的关键问题(通常与稳定性或安全性相关)。该版本中包含的唯一代码更改是针对特定关键问题的修复。重要的仅限文档的更改和安全的测试更新(如禁用测试)也可能包含在内,但仅此而已。

发布 Go 1.x+1 的小版本可以解决 Go 1.x 的非安全性问题。

Go 1.x+2 发行后,较小的发行版本可以解决 Go 1.x 的安全问题。有关安全更新的更多信息,请参阅安全策略。

另请参阅:https://github.com/golang/go/wiki/MinorReleases

历史

经过 14 个月的努力发布 Go 1.1 ,讨论并采用了 Go 发布周期。 Go 1.2,Go 1.3 和 Go 1.4 分别经历了六个月的周期,从 12 月 1 日和 6 月 1 日开始(或者是结束)。在经历了日历问题后,我们将 Go 1.5 的开发阶段延长了两个月,以转移 如上所述,该周期从 2 月 1 日和 8 月 1 日开始和结束。

最初的提案没有包含有关冻结期间里程碑的足够详细信息,并且在一些发行过程中,开发工作接管了大部分冻结。与上面设定的在发行冻结一个月内发布 Beta 的目标相比,Go 1.3,Go 1.4,Go 1.5 和 Go 1.6 的第一个 beta 分别晚了三,四,五和六周。 (Go 1.6 beta 1 仅晚了两周,但是它充满了我们仍然打算修复的已知错误,主要是为了在寒假之前拿出一些东西进行测试。按照上述定义,Go 1.6 的第一个实际 beta 是 beta 2.)

当 Beta 版本延迟时,在 Beta 版本之后发生的所有工作都将导致最终的 bug ,对候选版本的彻底测试以及发布发行版的交付变得匆忙,从而导致最终版本中出现更多bug,通常会延迟在 下一个周期启动。

在这 4个周期中,Beta 版的准备时间越来越晚,主要是因为我们都将太多的 bug 推迟到冻结阶段了,然后在冻结期间允许了很多不必要的 bug 修复。

对于 Go 1.7 及以后的版本,我们需要确保在冻结之前修复 bug 。 也就是说,我们需要遵循上面的时间表,而不是我们过去所做的那样。

参考资料

  1. https://github.com/golang/go/wiki/Go-Release-Cycle

茶歇驿站

一个可以让你停下来看一看,在茶歇之余给你帮助的小站,这里的内容主要是后端技术,个人管理,团队管理,以及其他个人杂想。