FreeBSD 发布工程

商标

FreeBSD 是 FreeBSD 基金会的注册商标。

Git 和 Git 徽标在美国和/或其他国家/地区是 Software Freedom Conservancy, Inc.（Git 项目的公司总部）的注册商标或商标。

Intel、Celeron、Centrino、Core、EtherExpress、i386、i486、Itanium、Pentium 和 Xeon 是 Intel Corporation 或其子公司在美国和其他国家/地区的商标或注册商标。

制造商和销售商用来区分其产品的许多名称都被宣称为商标。在本文档中出现这些名称的地方，如果 FreeBSD 项目知道商标声明，则这些名称后面会加上“™”或“®”符号。

1. FreeBSD 发布工程流程简介

FreeBSD 的开发具有非常特定的工作流程。一般来说，FreeBSD 基础系统的所有更改都提交到 main 分支，该分支反映了源代码树的顶端。

经过合理的测试期后，更改可以合并到 stable/ 分支。合并到 stable/ 分支的默认最短时间为三天 (3 天)。

尽管合并前等待至少三天的规则是普遍适用的，但在某些特殊情况下，可能需要立即合并，例如关键的安全修复或直接阻止发布构建过程的错误修复。

几个月后，stable/ 分支中的更改数量大幅增加，就该发布下一个版本的 FreeBSD 了。这些版本在历史上被称为“点”版本。

在 stable/ 分支的版本发布之间，大约每两年 (2 年) 会从 main 分支直接发布一个版本。这些版本在历史上被称为“点零”版本。

本文将重点介绍 FreeBSD 发布工程团队针对“点零”和“点”版本的流程和职责。

本文的以下部分描述

一般信息和准备: 开始发布周期之前的一般信息和准备。
发布周期中网站的更改: 发布周期中网站的更改
发布工程术语: 本文档中使用的术语和一般信息，例如“代码混杂”和“代码冻结”。
从 main 分支发布: “点零”版本的发布工程流程。
从 stable/ 分支发布: “点”版本的发布工程流程。
构建 FreeBSD 安装介质: 与构建安装介质的具体步骤相关的信息。
将 FreeBSD 安装介质发布到项目镜像: 发布安装介质的步骤。
结束发布周期: 结束发布周期。

2. 一般信息和准备

在发布周期开始前大约两个月，FreeBSD 发布工程团队会确定发布计划。该计划包括发布周期的各个里程碑点，例如冻结日期、分支日期和构建日期。例如

里程碑预计日期

里程碑	预计日期
main 代码混杂	2016 年 5 月 27 日
main 代码冻结	2016 年 6 月 10 日
main KBI 冻结	2016 年 6 月 24 日
`doc/` 树代码混杂 [1]	2016 年 6 月 24 日
Ports 季度分支 [2]	2016 年 7 月 1 日
stable/13 分支	2016 年 7 月 8 日
`doc/` 树标签 [3]	2016 年 7 月 8 日
BETA1 构建开始	2016 年 7 月 8 日
main 代码解冻	2016 年 7 月 9 日
BETA2 构建开始	2016 年 7 月 15 日
BETA3 构建开始 [*]	2016 年 7 月 22 日
releng/13.0 分支	2016 年 7 月 29 日
RC1 构建开始	2016 年 7 月 29 日
stable/13 代码解冻	2016 年 7 月 30 日
RC2 构建开始	2016 年 8 月 5 日
最终 Ports 包构建 [4]	2016 年 8 月 6 日
Ports 发布标签	2016 年 8 月 12 日
RC3 构建开始 [*]	2016 年 8 月 12 日
正式版构建开始	2016 年 8 月 19 日
正式版发布公告	2016 年 9 月 2 日

main 代码混杂

2016 年 5 月 27 日

main 代码冻结

2016 年 6 月 10 日

main KBI 冻结

2016 年 6 月 24 日

doc/ 树代码混杂 [1]

2016 年 6 月 24 日

Ports 季度分支 [2]

2016 年 7 月 1 日

stable/13 分支

2016 年 7 月 8 日

doc/ 树标签 [3]

2016 年 7 月 8 日

BETA1 构建开始

2016 年 7 月 8 日

main 代码解冻

2016 年 7 月 9 日

BETA2 构建开始

2016 年 7 月 15 日

BETA3 构建开始 [*]

2016 年 7 月 22 日

releng/13.0 分支

2016 年 7 月 29 日

RC1 构建开始

2016 年 7 月 29 日

stable/13 代码解冻

2016 年 7 月 30 日

RC2 构建开始

2016 年 8 月 5 日

最终 Ports 包构建 [4]

2016 年 8 月 6 日

Ports 发布标签

2016 年 8 月 12 日

RC3 构建开始 [*]

2016 年 8 月 12 日

正式版构建开始

2016 年 8 月 19 日

正式版发布公告

2016 年 9 月 2 日

标有“[*]”的项目为“按需”。

doc/ 树代码混杂由 FreeBSD 文档工程团队协调。
使用的 Ports 季度分支由计划进行最终 RC 构建的时间确定。季度分支在季度的第一天创建，因此在考虑发布周期里程碑时应使用此指标。季度分支由 FreeBSD Ports 管理团队创建。
doc/ 树由 FreeBSD 文档工程团队标记。
最终 Ports 包构建由 FreeBSD Ports 管理团队在最终（或预计为最终）RC 构建后完成。

如果版本是从现有的 stable/ 分支创建的，则可以排除 KBI 冻结日期，因为 KBI 已被认为在已建立的 stable/ 分支上冻结。

编写发布周期计划时，需要考虑许多因素，特别是目标日期取决于预定义里程碑的里程碑，这些里程碑存在依赖关系。例如，Ports 集合发布标签源自上次 RC 时的活动季度分支。这在一定程度上定义了使用哪个季度分支、发布标签何时可以发生以及最终 正式版 构建使用哪个版本的 ports 树。

在对计划达成普遍共识后，FreeBSD 发布工程团队会将计划通过电子邮件发送给 FreeBSD 开发人员。

许多开发人员会通知 FreeBSD 发布工程团队他们正在进行的各种工作，这很常见。在某些情况下，会请求延长正在进行的工作的时间，而在其他情况下，会请求对树的特定子集进行“全面批准”。

提出此类请求时，务必确保讨论时间线（即使是估计的时间线）。对于全面批准，应明确说明全面批准的持续时间。例如，FreeBSD 开发人员可能会请求从代码混杂开始到 RC 构建开始的全面批准。

为了跟踪全面批准，FreeBSD 发布工程团队使用内部存储库来维护此类请求的运行日志，其中定义了授予全面批准的区域、作者、全面批准过期时间以及授予批准的原因。例如，授予所有 FreeBSD 发布工程团队成员对 release/doc/ 的全面批准，直到最终 RC 以更新发行说明和其他与发行相关的文档。

FreeBSD 发布工程团队还使用此存储库来跟踪在发布周期期间开始各种构建之前收到的待批准请求，发布工程师会通过电子邮件向 FreeBSD 开发人员指定截止期限。

根据所讨论的底层代码集以及代码集对 FreeBSD 的整体影响，FreeBSD 发布工程团队可能会批准或拒绝此类请求。

正在进行的工作扩展也适用相同原则。例如，可能会延长与树的其余部分隔离的新设备驱动程序的正在进行的工作。但是，新的调度程序可能不可行，尤其是在其他分支中不存在此类重大更改的情况下。

该计划还添加到项目网站，位于 doc/ 存储库中的 ~/website/content/en/releases/13.0R/schedule.adoc 文件中。随着发布周期的进行，此文件会不断更新。

在大多数情况下，可以从以前的版本复制 schedule.adoc 并进行相应更新。

除了将 schedule.adoc 添加到网站之外，还会更新 ~/shared/releases.adoc 以将计划链接添加到各个子页面，并在项目网站索引页面上启用计划链接。

该计划也链接自 ~/website/content/en/releng/_index.adoc。

在计划的“代码混杂”前大约一个月，FreeBSD 发布工程团队会向 FreeBSD 开发人员发送提醒电子邮件。

3. 发布工程术语

本节描述了本文档其余部分中使用的一些术语。

3.1. 代码混杂

尽管代码混杂不会对树进行硬冻结，但 FreeBSD 发布工程团队会请求将现有代码库中的错误优先于新功能。

代码混杂不会强制执行对分支的提交审批。

3.2. 代码冻结

代码冻结标志着对分支的所有提交都需要 FreeBSD 发布工程团队明确批准的时间点。

FreeBSD Git 存储库包含多个钩子，用于在任何提交实际提交到树之前执行健全性检查。其中一个钩子将评估是否对特定分支进行提交需要特定的批准。

为了强制执行 FreeBSD 发布工程团队的提交审批，发布工程团队必须批准对分支的任何更改，在这种情况下，提交日志必须包含一行 Approved by: re (login)，其中“login”是批准者的登录 ID。

在代码冻结期间，FreeBSD 提交者应遵循更改请求指南。

3.3. KBI/KPI 冻结

KBI/KPI 稳定性意味着，在实现该函数的两个不同软件版本中，调用该函数会导致相同的最终状态。调用者，无论是进程、线程还是函数，都期望该函数以某种方式运行，否则该分支上的 KBI/KPI 稳定性就会被破坏。

4. 发布周期期间的网站更改

本节描述了随着发布周期的进展，网站应该发生的更改。

本节中指定的全部文件都相对于 doc 仓库的 main 分支。

4.1. 发布周期开始前的网站更改

当发布周期计划可用时，需要更新这些文件以在 FreeBSD 项目网站上启用不同的功能

要编辑的文件更改内容

要编辑的文件	更改内容
~/shared/releases.adoc	将 `beta-upcoming` 从 `IGNORE` 更改为 `INCLUDE`
~/shared/releases.adoc	将 `beta-testing` 从 `IGNORE` 更改为 `INCLUDE`

~/shared/releases.adoc

将 beta-upcoming 从 IGNORE 更改为 INCLUDE

~/shared/releases.adoc

将 beta-testing 从 IGNORE 更改为 INCLUDE

4.2. `BETA` 或 `RC` 期间的网站更改

从 PRERELEASE 转换到 BETA 时，需要更新这些文件以在下载页面上启用“帮助测试”块。所有文件都相对于 doc 仓库中的 head/。

要编辑的文件更改内容

要编辑的文件	更改内容
~/shared/releases.adoc	将 `betarel-vers` 更新为 `BETA1`
~/website/data/en/news/news.toml	添加一条公告，宣布 `BETA` 版本
~/website/static/security/advisory-template.txt	在模板中添加新的 `BETA`、`RC` 或最终 `RELEASE` 版本
~/website/static/security/errata-template.txt	在模板中添加新的 `BETA`、`RC` 或最终 `RELEASE` 版本

~/shared/releases.adoc

将 betarel-vers 更新为 BETA1

~/website/data/en/news/news.toml

添加一条公告，宣布 BETA 版本

~/website/static/security/advisory-template.txt

在模板中添加新的 BETA、RC 或最终 RELEASE 版本

~/website/static/security/errata-template.txt

在模板中添加新的 BETA、RC 或最终 RELEASE 版本

创建 releng/13.0 分支后，需要将各种与版本相关的文档添加到 doc/ 仓库中。

相关的版本相关文档存在于 FreeBSD 12.x 及更高版本的 doc 仓库中。

4.3. `BETA`、`RC` 和最终 `RELEASE` 期间的 Ports 更改

在发布周期中的每次构建过程中，包含各种发行版集（例如 base.txz、kernel.txz 等）的 SHA256 的 MANIFEST 文件将添加到 misc/freebsd-release-manifests 端口。这允许除之外的其他实用程序（例如 ports-mgmt/poudriere）通过提供一种验证校验和的机制来安全地使用这些发行版集。

5. 从 main 分支发布

本节描述了 FreeBSD 从 main 分支发布周期的通用流程。

5.1. FreeBSD “ALPHA” 构建

从 FreeBSD 10.0-RELEASE 发布周期开始，引入了“ALPHA”构建的概念。与 BETA 和 RC 构建不同，ALPHA 构建不包含在 FreeBSD 发布计划中。

ALPHA 构建的理念是在创建 stable/ 分支之前提供 FreeBSD 提供的定期构建。

FreeBSD ALPHA 快照应该大约每周构建一次。

对于第一次 ALPHA 构建，需要将 sys/conf/newvers.sh 中的 BRANCH 值从 CURRENT 更改为 ALPHA1。对于后续的 ALPHA 构建，将每个 ALPHAN 值加 1。

有关构建 ALPHA 镜像的信息，请参阅构建 FreeBSD 安装介质。

5.2. 创建 stable/13 分支

创建 stable/ 分支时，需要在新的 stable/ 分支和 main 分支中进行一些更改。列出的文件相对于仓库根目录。要使用 Git 创建新的 stable/13 分支

确保您位于 main 分支中

% git checkout -b stable/13

创建 stable/13 分支后，进行以下编辑

要编辑的文件更改内容

要编辑的文件	更改内容
更新	更新 FreeBSD 版本，并删除关于 `WITNESS` 的通知
contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h	`#ifndef MALLOC_PRODUCTION #define MALLOC_PRODUCTION #endif`
lib/clang/llvm.build.mk	取消注释 `-DNDEBUG`
sys//conf/GENERIC	删除调试支持
sys/*/conf/MINIMAL	删除调试支持
release/release.conf.sample	更新 `SRCBRANCH`
sys/*/conf/GENERIC-NODEBUG	删除这些内核配置
sys/arm/conf/std.arm*	删除调试选项
sys/conf/newvers.sh	将 `BRANCH` 值更新为 `BETA1`
share/mk/src.opts.mk	将 `REPRODUCIBLE_BUILD` 从 `__DEFAULT_NO_OPTIONS` 移动到 `__DEFAULT_YES_OPTIONS`
share/mk/src.opts.mk	将 `LLVM_ASSERTIONS` 从 `__DEFAULT_YES_OPTIONS` 移动到 `__DEFAULT_NO_OPTIONS`
libexec/rc/rc.conf	将 `dumpdev` 从 `AUTO` 设置为 `NO`（对于那些希望默认启用它的人，可以通过进行配置）
release/Makefile	删除 `debug.witness.trace` 条目

更新

更新 FreeBSD 版本，并删除关于 WITNESS 的通知

contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h

#ifndef MALLOC_PRODUCTION
#define MALLOC_PRODUCTION
#endif

lib/clang/llvm.build.mk

取消注释 -DNDEBUG

sys/*/conf/GENERIC*

删除调试支持

sys/*/conf/MINIMAL

删除调试支持

release/release.conf.sample

更新 SRCBRANCH

sys/*/conf/GENERIC-NODEBUG

删除这些内核配置

sys/arm/conf/std.arm*

删除调试选项

sys/conf/newvers.sh

将 BRANCH 值更新为 BETA1

share/mk/src.opts.mk

将 REPRODUCIBLE_BUILD 从 __DEFAULT_NO_OPTIONS 移动到 __DEFAULT_YES_OPTIONS

share/mk/src.opts.mk

将 LLVM_ASSERTIONS 从 __DEFAULT_YES_OPTIONS 移动到 __DEFAULT_NO_OPTIONS

libexec/rc/rc.conf

将 dumpdev 从 AUTO 设置为 NO（对于那些希望默认启用它的人，可以通过进行配置）

release/Makefile

删除 debug.witness.trace 条目

然后在 main 分支中，它将成为一个新的主版本

要编辑的文件更改内容

要编辑的文件	更改内容
更新	更新 FreeBSD 版本
sys/conf/newvers.sh	将 `BRANCH` 值更新为 `CURRENT`，并递增 `REVISION`
Makefile.inc1	更新 `TARGET_TRIPLE` 和 `MACHINE_TRIPLE`
sys/sys/param.h	更新 `__FreeBSD_version`
gnu/usr.bin/cc/cc_tools/freebsd-native.h	更新 `FBSD_MAJOR` 和 `FBSD_CC_VER`
contrib/gcc/config.gcc	附加 `freebsdversion.h` 部分
lib/clang/llvm.build.mk	更新 `OS_VERSION` 的值
lib/clang/freebsd_cc_version.h	更新 `FREEBSD_CC_VERSION`
lib/clang/include/lld/Common/Version.inc	更新 `LLD_REVISION_STRING`
Makefile.libcompat	更新 `LIB32CPUFLAGS`

更新

更新 FreeBSD 版本

sys/conf/newvers.sh

将 BRANCH 值更新为 CURRENT，并递增 REVISION

Makefile.inc1

更新 TARGET_TRIPLE 和 MACHINE_TRIPLE

sys/sys/param.h

更新 __FreeBSD_version

gnu/usr.bin/cc/cc_tools/freebsd-native.h

更新 FBSD_MAJOR 和 FBSD_CC_VER

contrib/gcc/config.gcc

附加 freebsdversion.h 部分

lib/clang/llvm.build.mk

更新 OS_VERSION 的值

lib/clang/freebsd_cc_version.h

更新 FREEBSD_CC_VERSION

lib/clang/include/lld/Common/Version.inc

更新 LLD_REVISION_STRING

Makefile.libcompat

更新 LIB32CPUFLAGS

6. 从 stable/ 分支发布

本节描述了 FreeBSD 从已建立的 stable/ 分支发布周期的通用流程。

6.1. FreeBSD `stable` 分支代码准备阶段

为准备在 stable 分支上进行代码冻结，需要更新几个文件以反映发布周期已正式开始。这些文件都相对于 stable 分支的顶层目录

要编辑的文件更改内容

要编辑的文件	更改内容
sys/conf/newvers.sh	将 `BRANCH` 值更新为 `PRERELEASE`
Makefile.inc1	更新 `TARGET_TRIPLE`
lib/clang/llvm.build.mk	更新 `OS_VERSION`
Makefile.libcompat	更新 `LIB32CPUFLAGS`

sys/conf/newvers.sh

将 BRANCH 值更新为 PRERELEASE

Makefile.inc1

更新 TARGET_TRIPLE

lib/clang/llvm.build.mk

更新 OS_VERSION

Makefile.libcompat

更新 LIB32CPUFLAGS

6.2. FreeBSD `BETA` 构建

在代码准备阶段之后，发布周期的下一阶段是代码冻结。这是 stable 分支的所有提交都需要 FreeBSD 发布工程团队明确批准的点。这由 gitadm@FreeBSD.org 强制执行，后者负责仓库管理。

在发布周期期间，有两个普遍的例外情况不需要提交批准。第一种是发布工程师为了推进发布周期的日常工作流程而需要提交的任何更改，另一种是在发布周期期间可能发生的安全性修复。

一旦代码冻结生效，该分支的下一个构建将标记为 BETA1。这是通过将 sys/conf/newvers.sh 中的 BRANCH 值从 PRERELEASE 更新为 BETA1 来完成的。

完成此操作后，将启动第一组 BETA 构建。后续的 BETA 构建不需要更新任何文件，除了 sys/conf/newvers.sh，递增 BETA 构建编号即可。

6.3. 创建 releng/13.0 分支

当第一个 RC（候选版本）构建准备开始时，将创建 releng/ 分支。这是一个多步骤过程，必须按特定顺序进行，以避免出现异常，例如 __FreeBSD_version 值重叠等。下面列出的路径相对于仓库根目录。提交顺序和更改内容如下

确保您位于 stable/13 分支中

% git checkout -b releng/13.0

要编辑的文件更改内容

要编辑的文件	更改内容
sys/conf/newvers.sh	将 `BETAX` 更改为 `RC1`
sys/sys/param.h	更新 `__FreeBSD_version`
sys/conf/kern.opts.mk	将 `REPRODUCIBLE_BUILD` 从 `DEFAULT_NO_OPTIONS` 移动到 `DEFAULT_YES_OPTIONS`
etc/pkg/FreeBSD.conf	将 `latest` 替换为 `quarterly` 作为默认的软件包仓库位置
release/pkg_repos/release-dvd.conf	将 `latest` 替换为 `quarterly` 作为默认的软件包仓库位置
sys/conf/newvers.sh	将 `BETAX` 更新为 `PRERELEASE`
sys/sys/param.h	更新 `__FreeBSD_version`

sys/conf/newvers.sh

将 BETAX 更改为 RC1

sys/sys/param.h

更新 __FreeBSD_version

sys/conf/kern.opts.mk

将 REPRODUCIBLE_BUILD 从 DEFAULT_NO_OPTIONS 移动到 DEFAULT_YES_OPTIONS

etc/pkg/FreeBSD.conf

将 latest 替换为 quarterly 作为默认的软件包仓库位置

release/pkg_repos/release-dvd.conf

将 latest 替换为 quarterly 作为默认的软件包仓库位置

sys/conf/newvers.sh

将 BETAX 更新为 PRERELEASE

sys/sys/param.h

更新 __FreeBSD_version

然后，gitadm@FreeBSD.org 为 releng 分支添加新的批准者，就像为 stable 分支所做的那样。

% git add .
% git commit

现在，由于存在两个新的 __FreeBSD_version 值，还需要在文档项目仓库中的 ~/documentation/content/en/books/porters-handbook/versions/chapter.adoc 中进行更新。

第一个 RC 构建完成并经过测试后，gitadm@FreeBSD.org 可以“解冻” stable/ 分支。

第一个 RC 发布后，应向 FreeBSD Bugmeister 团队发送电子邮件，要求他们在错误跟踪器中显示的下拉菜单中添加新的 FreeBSD -RELEASE 版本。

7. 构建 FreeBSD 安装介质

本节描述了生成 FreeBSD 开发快照和版本的通用流程。

7.1. 发布构建脚本

在 FreeBSD 9.0-RELEASE 之前，更新了 src/release/Makefile 以支持，并引入了 src/release/generate-release.sh 脚本作为包装器来自动调用目标。

在 FreeBSD 9.2-RELEASE 之前，引入了 src/release/release.sh，它在很大程度上基于 src/release/generate-release.sh，包括支持指定配置文件以覆盖各种选项和环境变量。配置文件的支持通过为每次调用指定单独的配置文件来支持为每个版本的每个体系结构进行交叉构建。

使用 src/release/release.sh 在 /scratch 中构建单个版本的简要示例

# /bin/sh /usr/src/release/release.sh

使用 src/release/release.sh 使用不同的目标目录构建单个交叉构建版本的简要示例，创建一个包含以下内容的自定义 release.conf 文件

# release.sh configuration for powerpc/powerpc64
CHROOTDIR="/scratch-powerpc64"
TARGET="powerpc"
TARGET_ARCH="powerpc64"
KERNEL="GENERIC64"

然后像这样调用 src/release/release.sh：

# /bin/sh /usr/src/release/release.sh -c $HOME/release.conf

有关更多详细信息和使用示例，请参阅和 src/release/release.conf.sample。

7.2. 构建 FreeBSD 版本

在发布周期中，每个架构的 CHECKSUM.SHA512 和 CHECKSUM.SHA256 的副本除了包含在各种公告邮件中外，还会存储在 FreeBSD 发布工程团队的内部仓库中。每个包含 base.txz、kernel.txz 等哈希值的 MANIFEST 文件也会添加到 Ports Collection 中的 misc/freebsd-release-manifests。

在准备发布版本构建时，需要更新几个文件。

要编辑的文件更改内容

要编辑的文件	更改内容
sys/conf/newvers.sh	将 `BRANCH` 值更新为 `RELEASE`
更新	添加预期的公告日期
lib/csu/common/crtbrand.S	将 `__FreeBSD_version` 替换为 sys/sys/param.h 中的值。

sys/conf/newvers.sh

将 BRANCH 值更新为 RELEASE

更新

添加预期的公告日期

lib/csu/common/crtbrand.S

将 __FreeBSD_version 替换为 sys/sys/param.h 中的值。

在构建最终的 RELEASE 后，releng/13.0 分支将使用构建 RELEASE 的修订版本标记为 release/13.0.0。与创建 stable/13 和 releng/13.0 分支类似，这使用 git tag 完成。从仓库根目录执行以下操作：

确保您位于 releng/13.0 分支中。

% git tag release/13.0.0

8. 将 FreeBSD 安装介质发布到项目镜像

本节描述将 FreeBSD 开发快照和版本发布到项目镜像的过程。

8.1. 准备 FreeBSD 安装介质镜像

准备 FreeBSD 快照和版本是一个两部分的过程。

创建与 ftp-master 上的层次结构匹配的目录结构。
如果在构建配置文件（例如上面引用的构建脚本中的 main.conf）中定义了 EVERYTHINGISFINE，则构建完成后会自动执行此操作，在 ${DESTDIR}/R/ftp-stage 中创建与 ftp-master 上期望的路径结构匹配的目录结构。这等效于在目录中运行以下命令：
```
# make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage
```
每个架构构建完成后，thermite.sh 将分别从构建主机上的 ${DESTDIR}/R/ftp-stage 使用 rsync 同步到构建主机上的 /snap/ftp/snapshots 或 /snap/ftp/releases。
在将文件移动到 pub/ 开始传播到项目镜像之前，将文件复制到 ftp-master 上的暂存目录。
所有构建完成后，ftp-master 将使用 rsync 轮询 /snap/ftp/snapshots（对于快照）或 /snap/ftp/releases（对于版本），分别将其复制到 /archive/tmp/snapshots 或 /archive/tmp/releases。
在 FreeBSD 项目基础设施的 ftp-master 上，此步骤需要 root 级别访问权限，因为此步骤必须以 archive 用户身份执行。

8.2. 发布 FreeBSD 安装介质

一旦镜像在 /archive/tmp/ 中暂存，就可以通过将其放入 /archive/pub/FreeBSD 来公开它们。为了减少传播时间，使用硬链接从 /archive/tmp 到 /archive/pub/FreeBSD。

为了使此方法有效，/archive/tmp 和 /archive/pub 必须位于同一个逻辑文件系统上。

但是，有一个需要注意的地方，之后必须使用 rsync 来更正 pub/FreeBSD/snapshots/ISO-IMAGES 中的符号链接，这将替换为硬链接，从而增加传播时间。

与暂存步骤一样，此步骤需要 root 级别访问权限，因为此步骤必须以 archive 用户身份执行。

以 archive 用户身份执行以下操作：

% cd /archive/tmp/snapshots
% pax -r -w -l . /archive/pub/FreeBSD/snapshots
% /usr/local/bin/rsync -avH /archive/tmp/snapshots/* /archive/pub/FreeBSD/snapshots/

根据需要将 snapshots 替换为 releases。

9. 完成发布周期

本节描述一般的发布后任务。

9.1. 发布后勘误通知

随着发布周期接近尾声，通常会有一些 EN（勘误通知）候选者来解决在周期后期发现的问题。发布后，FreeBSD 发布工程团队和 FreeBSD 安全团队会重新审视在最终发布之前未批准的更改，并根据相关更改的范围，可能会发布 EN。

发布 EN 的实际过程由 FreeBSD 安全团队处理。

要请求在发布周期完成后发布勘误通知，开发人员应填写勘误通知模板，特别是 Background、Problem Description、Impact 以及（如果适用）Workaround 部分。

填写完整的勘误通知模板应与针对 releng/ 分支的补丁或来自 stable/ 分支的修订版本列表一起发送电子邮件。

对于发布后立即的勘误通知请求，请求应发送给 FreeBSD 发布工程团队和 FreeBSD 安全团队。一旦 releng/ 分支已如移交给 FreeBSD 安全团队中所述移交给 FreeBSD 安全团队，则应将勘误通知请求发送给 FreeBSD 安全团队。

9.2. 移交给 FreeBSD 安全团队

发布大约两周后，发布工程师更新 Git 仓库，将审批人从发布工程团队更改为 releng/13.0 分支的安全官。

10. 版本生命周期结束

本节描述当版本达到 EoL（生命周期结束）时需要更新的与网站相关的文件。

10.1. 版本生命周期结束的网站更新

当版本达到生命周期结束时，应从网站上删除和/或更新对该版本的引用。

文件更改内容

文件	更改内容
~/website/themes/beastie/layouts/index.html	删除 `u-relXXX-announce` 和 `u-relXXX-announce` 引用。
~/website/content/en/releases/_index.adoc	将 `u-relXXX-*` 变量从受支持的版本列表移动到旧版本列表。
~/website/content/en/releng/_index.adoc	更新相应 releng 分支以反映该分支不再受支持。
~/website/content/en/security/_index.adoc	从受支持的分支列表中删除该分支。
~/website/content/en/security/unsupported.adoc	将该分支添加到不受支持的分支列表。
~/website/content/en/where.adoc	删除该版本的 URL。
~/website/themes/beastie/layouts/partials/sidenav.html	删除 `u-relXXX-announce` 和 `u-relXXX-announce` 引用。
~/website/static/security/advisory-template.txt	删除对该版本和 releng 分支的引用。
~/website/static/security/errata-template.txt	删除对该版本和 releng 分支的引用。

~/website/themes/beastie/layouts/index.html

删除 u-relXXX-announce 和 u-relXXX-announce 引用。

~/website/content/en/releases/_index.adoc

将 u-relXXX-* 变量从受支持的版本列表移动到旧版本列表。

~/website/content/en/releng/_index.adoc

更新相应 releng 分支以反映该分支不再受支持。

~/website/content/en/security/_index.adoc

从受支持的分支列表中删除该分支。

~/website/content/en/security/unsupported.adoc

将该分支添加到不受支持的分支列表。

~/website/content/en/where.adoc

删除该版本的 URL。

~/website/themes/beastie/layouts/partials/sidenav.html

删除 u-relXXX-announce 和 u-relXXX-announce 引用。

~/website/static/security/advisory-template.txt

删除对该版本和 releng 分支的引用。

~/website/static/security/errata-template.txt

删除对该版本和 releng 分支的引用。

上次修改时间：2024 年 9 月 20 日，作者：Fernando Apesteguía

FreeBSD 发布工程

目录

1. FreeBSD 发布工程流程简介

2. 一般信息和准备

3. 发布工程术语

3.1. 代码混杂

3.2. 代码冻结

3.3. KBI/KPI 冻结

4. 发布周期期间的网站更改

4.1. 发布周期开始前的网站更改

4.2. BETA 或 RC 期间的网站更改

4.3. BETA、RC 和最终 RELEASE 期间的 Ports 更改

5. 从 main 分支发布

5.1. FreeBSD “ALPHA” 构建

5.2. 创建 stable/13 分支

6. 从 stable/ 分支发布

6.1. FreeBSD stable 分支代码准备阶段

6.2. FreeBSD BETA 构建

6.3. 创建 releng/13.0 分支

7. 构建 FreeBSD 安装介质

7.1. 发布构建脚本

7.2. 构建 FreeBSD 版本

8. 将 FreeBSD 安装介质发布到项目镜像

8.1. 准备 FreeBSD 安装介质镜像

8.2. 发布 FreeBSD 安装介质

9. 完成发布周期

9.1. 发布后勘误通知

9.2. 移交给 FreeBSD 安全团队

10. 版本生命周期结束

10.1. 版本生命周期结束的网站更新

4.2. `BETA` 或 `RC` 期间的网站更改

4.3. `BETA`、`RC` 和最终 `RELEASE` 期间的 Ports 更改

6.1. FreeBSD `stable` 分支代码准备阶段

6.2. FreeBSD `BETA` 构建