FreeBSD 发布工程：新主管上任
最后更新于
最后更新于
原文链接：
作者：Colin Percival
2023 年 11 月 17 日，Glen Barber 在管理 FreeBSD 发布的十年后，正式卸任了 FreeBSD 发布工程主管一职。在 FreeBSD 核心团队的帮助下，我接替了这一角色。
Glen 在发布工程师岗位上表现出色，因此当我接手时，首要任务就是确保工作的延续性——尽可能沿用他之前的工作方式。得益于我担任发布工程副主管三年的经验（虽然只主导过一次版本发布——在 Glen 因肺炎住院期间负责的 FreeBSD 13.2-RELEASE），通过长期观摩 Glen 的工作方式，我对如何延续他的工作模式已经有了整体把握。
但这并不意味着我没有做出任何改变——如果是那样的话，这篇文章不会这么长。我的首要目标是简化发布流程，以免发生像 FreeBSD 13.2 那样的情况——FreeBSD 13.2 推迟了将近一个月，且发布了六个发布候选（RC）版本才解决了所有问题，方能得以继续发布。为此，我制定了一些发布周期的基本规则：
发布候选版本（RC）应该正如其名——是发布的候选版本（Release Candidate）——因此，到达 RC1 时应该没有已知妨碍发布的问题。我们的方向是构建 RC1，进行一周的测试（或略少于一周，考虑到构建完成的时间），然后构建最终的 RELEASE 镜像。如果在 RC1 中发现问题，我们可以再进行第二到第三个发布候选版本——但这应该仅发生在出现新问题时；应该在 RC1 之前就已经解决了任何已知的问题。
尽管开发者常常有代码“需要”在下个版本中发布，但如果他们迟到了，我不会因此延误发布流程——因为这样做对所有按时将代码合并到源代码树中的开发者来说是不公平的，他们希望能尽快把代码交到用户手中。直到 -BETA1 之前，源代码树是开放的，所有人都可以合并补丁（我们曾经会“冻结” Stable 分支，但近年来这已经不这么做了）。在 BETA1 和 BETA2 之间，我通常会接受那些不那么庞大和危险的修改，但在 BETA2 和 BETA3 之间，就要考虑“我们 确定 这个补丁不会引发任何新问题吗？”，而在 BETA3 和 RC1 之间，补丁的要求更高，必须满足“……并且它解决了用户遇到的实际问题”，因为如果问题纯粹是理论上的，就不值得冒险，怕补丁本身出问题。当然，RC1 之后，只会接受最关键的补丁——在理想情况下，甚至不接受补丁——因为此时的任何更改都需要增加一个新的发布候选版本，并推迟发布日期。
如果在接近发布时出现新特性——比如在“代码软冻结阶段（code slush）”后，BETA1 前两周——并且发现无法立即修复的问题，我将从发布中移除这些特性。过去发布日程经常拖延的部分原因是，特性到得太晚，然后需要多轮的错误修复才能完成发布；与晚到的代码一样，如果某个开发者在最后一刻合并了有问题的代码，导致了发布的延误，那对其他人来说也不公平。
我还要求 FreeBSD 开发者——虽然有时效果不一，但似乎逐渐有所改善——在提交代码到即将发布的版本时，要更加主动地提醒发布工程团队；只要得知了问题，我会更积极地通过邮件联系开发者，询问状态更新。曾多次收到类似“我没意识到 BETA2 已经发布了；我会尽快合并那个代码”的回复——FreeBSD 是个志愿者项目，所以开发者在生活中会有其他事情分心，从而忽视了 FreeBSD 的工作，这完全可以理解，但我们最不希望看到的就是因为某人失去时间感而导致发布日程推迟。
只要我们确认 FreeBSD 项目能够在可预测的时间内完成发布，我就开始考虑发布的具体安排。三个 BETA 镜像和一个 RC 总共需要一个月时间，我们在 BETA1 发布前有两周的“代码软冻结阶段”，并且在此之前还会有两周的提前警告期（也就是“赶紧把代码合并”）。若一切顺利，这将总共耗时 2 个月；但因为无论如何我们总是会有一些延误（至少因为我们总是会因最后时刻的安全修复而推迟发布），我们需要额外留出第三个月的时间来为发布日程提供灵活性，并给发布工程团队在发布之间留出一些时间。
在知道我们每三个月可以有效地发布一个版本后，发布的时间安排就变得显而易见：每个日历季度发布一个版本。如果我们从季度的第一个月开始，先是两周的“警告期”和两周的“代码软冻结阶段”，然后在第二个月每周发布 BETA 和 RC1，那么 RELEASE 公告就会出现在第三个月的开始。如果发布推迟了几周，我们仍然能在第三个月结束之前完成。这为后续的发布提供了一个目标日程——我们永远不会发布不成熟的版本，但明确我们方向是什么是一个必要的起点：
BETA1 前 28 天：向开发者发出警告。
BETA1 前 14 天：开始代码软冻结阶段。
第二个月的第一个星期五：发布 BETA1。
BETA1 + 7 天：发布 BETA2。
BETA1 + 14 天：发布 BETA3。
BETA1 + 21 天：发布 RC1。
BETA1 + 28 天：开始构建 RELEASE。
BETA1 + 32 天：发布 RELEASE 公告。
BETA1 + 39 天：将发布分支交给安全团队。
唯一的例外是 .0 版本：这些版本会在 Stable 分支创建之前从 ALPHA 构建开始，显然无法将整个 .0 版本的过程压缩到三个月内；因此，为了使其他版本的日程能够与日历季度对齐，我决定为这些版本预留六个月的时间——即两个日历季度。关于这六个月内的具体时间安排，我尚未决定——并且由于我没做过 .0 版本的发布，因此可能会在 15.0 上犯错——但我确实希望最终能够为这些版本建立一个可再现的发布计划。
只要确定了每个版本所需的时间，剩下的就是确定版本的发布顺序，并决定多久发布一次 .0 版本。第一个问题很容易回答：在同一个 Stable 分支发布之后的三个月内没有必要再发布一个新版本，所以我们将 Stable 分支之间交替发布，即 14.0、13.3、14.1、13.4、14.2 等等。第二个问题的答案来源于多年来 FreeBSD 开发者之间的讨论：我们希望每两年发布一个新的大版本。过去，.0 版本的发布周期通常是在 FreeBSD 开发者峰会后不久开始的——这确保了大量开发者可以参与讨论，希望在发布前完成的特性——由于最大规模的开发者峰会通常在 5月 或 6 月的 BSDCan 举行，因此将 .0 版本的发布安排在每个奇数年份的下半年，大约在 11 月或 12 月发布是合适的。
这就为每个 FreeBSD 版本的发布提供了时间表：
2025 年 6 月：FreeBSD 14.3
（2025 年 9 月：这一季度没有发布；正在开发 15.0）
2025 年 12 月：FreeBSD 15.0
2026 年 3 月：FreeBSD 14.4
2026 年 6 月：FreeBSD 15.1
2026 年 9 月：FreeBSD 14.5
2026 年 12 月：FreeBSD 15.2
2027 年 3 月：FreeBSD 14.6
2027 年 6 月：FreeBSD 15.3
（2027 年 9 月：没有发布；正在开发 16.0）
2027 年 12 月：FreeBSD 16.0
从 FreeBSD 11.0-RELEASE 开始，FreeBSD 对发布版本的支持政策是，次要版本在下一个来自同一 Stable 分支的版本发布后的三个月内得到支持，而 Stable 分支则从 .0 版本发布日起支持五年。
这一政策的前半部分——次要版本的支持持续时间——与新的季度发布计划非常契合：正如我们几乎每个季度末都会发布新版本一样，每个版本也会在每个季度末达到其生命周期的结束。此外，由于现在每个版本都会在每个季度的第三个月发布，“次要版本之间有三个月的重叠”这一政策实际上就变成了“一个季度的重叠”。
新发布计划与已确立的支持时间线不太契合的地方是对 Stable 版本的支持周期：每两年发布一次新的 .0 版本（从而创建新的 Stable 分支），并将每个 Stable 分支支持五年，会导致三个 Stable 分支同时受支持——经验告诉我们，这对于我们这样的项目来说并不容易做到。
因此，为了更好地将支持时间线与发布计划对齐，核心团队、安全团队和 Ports 管理团队批准了调整 Stable 分支的支持时间线：从 15.x 开始， Stable 分支将支持 4 年而不是 5 年。这听起来可能是个变化，但实际上，在第五年， Stable 分支的支持始终不太好。
通过这一改变，将始终有两个 Stable 分支得到支持，除了每两年会有一个短暂的窗口期，在此期间，当 (N+2).0 发布时，N.x 分支即将达到生命周期结束时，三个 Stable 分支会同时得到支持。
多年来，FreeBSD 网站的部分内容（有时被注释掉）提到过“过时（legacy）”版本，但据我所知，直到现在并没有明确说明“过时（legacy）”版本的定义。在 Glen 担任发布工程师期间，这一概念大多被弃用，因为他认为将一个版本称为“过时（legacy）”会误导用户，使其认为该版本质量较差，而实际上我们对所有 FreeBSD 版本的质量要求都是一样的。
我决定重新引入这一概念，帮助用户（尤其是新用户）决定应该安装哪个版本。为此，我给出了以下定义：
“过时（legacy）”版本是指尚未达到生命周期结束的版本，但发布工程团队不建议用于新系统的部署。
换句话说，它是为了那些已经安装了 FreeBSD 并且不想升级到最新版本的用户准备的；但如果你是安装新系统，应该选择一个较新的版本。
一般来说，只要 FreeBSD 的 N.1 版本发布，(N-1).x Stable 分支将被视为“过时（legacy）”，而当从 Stable 分支发布新的次要版本时，该分支的前一个版本立即变为“过时（legacy）”。换句话说：通常，除最新 Stable 分支的最新版本外，其他版本都被视为“过时（legacy）”，但在新的 Stable 分支以 .0 版本发布后，之前 Stable 分支的最新版本将保持为“非过时（non-legacy）”。
最终，FreeBSD 用户可以使用他们喜欢的任何版本，这并不意味着会限制 FreeBSD 开发者关于合并功能和修复错误的决策；这一点纯粹是为了帮助新手和经验不足的用户选择正确的版本进行下载。
在 2024 年，我已经做出了上述变化，并管理了 13.3、14.1、13.4 和 14.2 版本。那么接下来呢？
首先，我们已经安排了 2025 年的三个发布版本：13.5、14.3 和 15.0。到目前为止，我所做的次要版本每个都花费了 50 到 100 小时的时间（13.x 版本占用小，14.x 版本在占用大，因为 14.x 有更多新代码）。我很幸运得到了来自亚马逊的赞助，用于我的 FreeBSD 工作（不仅是为了在 EC2 平台上专门维护 FreeBSD，还包括一般的发布工程工作）——离开这个帮助，FreeBSD 14.2 版本在某些晚期功能的加入上可能会遇到困难，因为如果没有足够的时间，问题就无法及时解决。当然，FreeBSD 15.0 将是一个新的主要版本——这是我以前从未做过的——我确信它会花费更多的发布工程时间。
但除了“常规”流程，即每周发布快照和（大多数情况下）每季度发布之外，未来还有两项重要工作：首先，FreeBSD 15.0 应该会推出一款基于软件包的系统——pkgbase 已经“即将推出”太长时间了；其次，在主权技术机构资助下，FreeBSD 基金会正在资助一个项目来现代化 FreeBSD 的构建过程（特别是使得尽可能多的构建可以在没有 root 权限的情况下完成）。这两项工作都将涉及发布工程过程中的重大变化，但它们都不应影响我们按可预测的时间表推出 Stable 且经过充分测试的版本的目标。
Colin Percival 是 FreeBSD 发布工程负责人和 FreeBSD/EC2 平台的维护者，2019 年因其贡献被评为“AWS Hero”。他平时的本职工作是 Tarsnap 的创始人兼主要开发者，Tarsnap 是一家在线备份服务。