发布流程

本文档介绍了 Fuchsia 平台的发布流程。

在本文档中，“发布”一词是指生成和发布各种工件以供软件供应链中较靠后的开发者（例如组件作者或产品所有者）使用的行为。它并不是指向最终用户提供基于 Fuchsia 的产品的更新。

版本

Fuchsia 版本是一组生成的工件，这些工件是在给定时间点由 Fuchsia 项目输出，以特定发布版本名称发布。

其中包括：

• 集成器开发套件 (IDK)：这是构建和运行以 Fuchsia 为目标平台的程序所需的一小组库、软件包和工具。
  • 基于 IDK 的多个 SDK（例如 Bazel SDK）。
• 操作系统 (OS) 二进制文件，包括配置和组建 Fuchsia 产品软件包所需的内核、引导加载程序、软件包、工具和其他要素。
  • 多个预先组装的产品软件包（例如 Workbench 产品）¹。
• 各种其他工件，例如文档和针对 Fuchsia (CTF) build 的兼容性测试 build。

没有一个包含所有这些工件的单个归档文件；不同的工件由不同的构建器生成并上传到不同的代码库。有些工件可在线免费提供，有些则为机密。（实际上，IDK 和操作系统二进制文件都有公开变体和机密变体。）

而将他们团结在一起的是：

• 它们全部完全基于 Fuchsia 源代码树的单个修订版本（具体而言，integration.git² 的 Google 内部版本）构建而成，并且
• 它们会发布到同一发布版本下的相应代码库。

发布版本

发布版本是为发布版本命名的字符串。

每个发布版本在 Google 内部版本的 integration.git 中都有一个相应的标记，该标记不可变地指向构建发布版本的二进制工件的 git 提交。

版本命名为 M.YYYYMMDD.R.C（例如 2.20210213.2.5），其中

• M 表示此版本的“里程碑”。
• YYYYMMDD 是版本的历史记录与 main 分支的差异的日期。
• R 表示“发布”版本号。该值从 0 开始，如果同一日期创建了多个版本，则会递增。
• C 表示“候选”版本号。此数量从 1 开始，在对里程碑版本分支中的上一个版本进行更改时递增。

Canary 版本

系统每天会创建几次 ³ Canary 版本，具体取决于 Fuchsia 源代码树的最后一个已知良好的修订版本。具体而言，Google 内部版本的 integration.git 中将 Git 标记应用于该修订版本，并触发各种构建器以构建和发布上述工件。Canary 版本没有自己的版本分支，只有标记。

每个 Canary 版本都只在下一个 Canary 版本发布前维持很短的一段时间。我们没有为 Canary 版本择优挑选 bug 修复。（换句话说：Canary 版本的“候选”版本号应始终为“1”。）如果在 Canary 版本中发现 bug，则会将针对该 bug 的修复应用于 Fuchsia 源代码树的 main 分支。受该 bug 影响的客户端应回滚到早期版本，并/或等待包含修复的后续 Canary 版本。

因此，Canary 版本适用于开发和测试，但可能不适合生产。对于生产使用场景，最好使用里程碑版本。

里程碑版本

每隔几周，我们都会从现有“已知良好”Canary 版本的 Git 提交开始，在 Google 内部版本和 integration.git 的公共镜像中创建一个里程碑版本分支。源自里程碑版本分支的版本称为“里程碑版本”或“稳定版本”。

里程碑会按顺序编号，并且在讨论时通常会以“F”为前缀（例如，“F12 版本分支”）。

FN 里程碑版本分支被剪切后，Fuchsia 源代码树中的 Mainline 开发将继续在 main 分支上进行，面向下一个 FN+1 版本，并且 Canary 版本的版本将以 N+1 开头，如下图所示：

里程碑版本与其所基于的 Canary 版本共享其版本的 M.YYYYMMDD.R 部分，因此只有基于给定里程碑版本分支构建的各版本之间的“候选”版本号 C 才会发生变化。请注意，这意味着有时很难看出某个版本是 Canary 版本还是里程碑版本（不过，C 值大于 1 表示版本来自里程碑版本分支）。

与 Canary 版本不同，里程碑版本在创建后的数周内受支持。也就是说，在版本分支切割后，可以对里程碑版本分支进行改进。对里程碑版本分支进行每次更改后，都会发布一个新的里程碑版本，并采用更大的“候选”版本号。

一般而言：

• 功能是在 main（而非里程碑版本分支）中开发的。
• 对里程碑版本分支所做的更改首先在 main 上进行，然后会被择优挑选到分支上。
• 里程碑版本分支只会对用于修复 bug（与质量、安全性、隐私权、合规性等方面相关的更改）进行相应更改。我们不会做出会向里程碑版本分支引入新功能的更改。

这些政策旨在最大限度地降低对里程碑版本分支的更改引入新 bug 的可能性，因此与给定里程碑相关联的版本的可靠性和稳定性应该会随着时间的推移而提高。因此，我们建议下游客户尽快采用这些新的里程碑版本。

在某些特殊情况下，我们可能需要偏离这些政策（例如，可能需要在机密分支上开发安全修复程序，以避免在修复程序准备就绪之前将漏洞公开）。是否添加对里程碑版本分支的更改最终由版本管理员决定。

向后兼容性

Fuchsia 项目承诺单个版本（无论是 Canary 版本还是里程碑版本）中的所有工件相互兼容。例如，如果开发者使用 SDK 版本 2.20210213.2.5 构建组件，我们承诺该组件将在操作系统版本为 2.20210213.2.5 的 Fuchsia 设备上运行。在这些情况下，组件如果从 Fuchsia 平台看到错误行为，将被视为 bug。

严格地讲，截至撰写本文时，Fuchsia 并不对任何两个版本之间的 API 或 ABI 兼容性提供正式保证，现有的 RFC 均未讨论此问题。但实际上，使用某个版本的 SDK 构建的 Fuchsia 组件经常在基于不同版本的 Fuchsia 系统上运行，但我们仍然可以解决在这些配置中发现的问题。

在未来的 RFC 中，我们将对各版本之间的 API 和 ABI 兼容性有条件地承诺。

文档历史记录

• 最初在 RFC-0227 中引入。