Release

Fuchsia 版本是一组生成的制品，是 Fuchsia 项目在特定时间点的输出，以特定的版本名称发布。每个 Fuchsia 版本都实现了相应一组 API 级别的 ABI，因此可以运行任何 build 时目标 API 级别位于该组中的组件。

版本包含以下内容：

  • 集成器开发套件 (IDK)，一组用于构建和运行以 Fuchsia 为目标的程序所需的小型库、软件包和工具。
    • 少量基于 IDK 的 SDK（例如 Bazel SDK）。
  • 操作系统 (OS) 二进制文件，包括内核、引导加载程序、软件包、工具以及配置和组装 Fuchsia 产品包所需的其他要素。
    • 许多预组装的产品套装（例如，工作台产品）1。
  • 各种其他制品，例如文档和 Fuchsia 兼容性测试 (CTF) 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 开始，并在对里程碑版本分支上的先前版本进行更改时递增。

发布流程

Fuchsia 有以下类型的版本：

Canary 版本

每天会创建几次2基于 Fuchsia 源代码树的最新已知良好修订版本的 canary 版本。具体来说，系统会在 integration.git 的 Google 内部版本中对相应修订版本应用 Git 标记，并触发各种构建器来构建和发布上述制品。Canary 版不会获得自己的发布分支，只会获得标记。

每个 Canary 版仅在短时间内（即在下一个 Canary 版发布之前）受支持。Bug 修复不会被择优挑选到 Canary 版中。（换句话说，Canary 版本的“候选”版本号应始终为“1”。）如果在 Canary 版中发现 bug，则会针对 Fuchsia 源代码树的 main 分支应用该 bug 的修复。受该 bug 影响的客户应回滚到之前的版本，并/或等待包含相应修复的后续 Canary 版。

因此，Canary 版适合用于开发和测试，但不建议用于生产环境。对于生产用例，建议使用里程碑版本。

里程碑版本

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

里程碑按数字顺序排列，在讨论时通常以“F”为前缀（例如，“F12 发布分支”）。

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

一张图表，其中彩色箭头表示 Fuchsia 里程碑。F11 最初位于主分支上，但随后分支出来，成为 F11 分支。之后，主分支被标记为 F12，再次分支，依此类推。

里程碑版本与其所基于的金丝雀版本共享版本号的 M.YYYYMMDD.R 部分，因此，从给定的里程碑版本分支构建的版本之间，只有“候选”版本号 C 会发生变化。请注意，这意味着，从版本中并不总是能立即看出相应版本是 Canary 版还是里程碑版本（不过，如果 C 的值大于 1，则表示相应版本来自里程碑版本分支）。

与 Canary 版不同，里程碑版本在创建后会受支持一段时间。也就是说，在发布分支切断后，可能会对里程碑版本分支进行改进。每次对里程碑版本分支进行更改后，系统都会发布新的里程碑版本，其“候选”版本号会更大。

main上的开发

根据一般政策：

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

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

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

  1. 其中一些产品是出于纯粹的历史原因在 Fuchsia 源代码树中定义的，未来将移出树外，以促进产品与平台之间的分离。 ↩

  2. 本文档未指定任何特定的发布节奏。时间段的命名是为了提供各种流程的频次“数量级”估计值。随着项目和客户需求的变化，节奏也会随之变化。 ↩