| RFC-0227：Fuchsia 发布流程 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 介绍 Fuchsia 的 SDK 和操作系统发布流程 |
| 问题 |
|
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-08-14 |
| 审核日期（年-月-日） | 2023-10-02 |
总结
此 RFC 规定了发布 Fuchsia 平台的现有流程。
在本 RFC 中，“发布”一词是指生成和发布各种工件以供软件供应链中较靠后的开发者（例如组件作者或产品所有者）使用的行为。它并不是指向最终用户提供基于 Fuchsia 的产品的更新。
设计初衷
Fuchsia 已经推出几年的功能发布流程。不过，虽然外部观察者可以看到 Fuchsia 版本和里程碑版本分支，但目前还没有一个 RFC 规范记录和定义此流程。
早期的 Fuchsia 版本需要与我们的下游合作伙伴密切合作，但每个通过的里程碑都没有比以往更加特殊，也更单调。
为了延续这种走向成熟的趋势，每位 Fuchsia 开发者都需要了解他们在防止我们的版本对下游合作伙伴发挥的作用。因此，此 RFC 对现有 Fuchsia 发布流程进行了编码，这些部分对平台贡献者而言最为重要。
利益相关方
教员：davemoore@google.com
审核者：
- billingstevenson@google.com，解禁项目管理主管
- abarth@google.com，相关 RFC-0002 的作者
- atyfto@google.com，共同作者和基础架构负责人
咨询人员：aaronwood@google.com、chaselatta@google.com、sethladd@google.com
社交：与专家一起探讨，以验证它是否准确反映了世界的当前状态。
要求
此 RFC 说明了目前的发布流程。它没有规定任何更改。
如上所述，本 RFC 不讨论向最终用户交付软件。此 RFC 中描述的工件已发送给开发者和产品所有者。他们使用这些工件来构建软件，最终通过超出此 RFC 说明的流程将其交付给最终用户。
设计
Fuchsia 版本是一组生成的工件，这些工件是在给定时间点由 Fuchsia 项目输出，以特定发布版本名称发布。
其中包括：
- 集成器开发套件 (IDK)：这是构建和运行以 Fuchsia 为目标平台的程序所需的一小组库、软件包和工具。
- 基于 IDK 的多个 SDK（例如 Bazel SDK）。
- 操作系统 (OS) 二进制文件，包括配置和组建 Fuchsia 产品软件包所需的内核、引导加载程序、软件包、工具和其他要素。
- 各种其他工件，例如文档和针对 Fuchsia (CTF) build 的兼容性测试 build。
没有一个包含所有这些工件的单个归档文件；不同的工件由不同的构建器生成并上传到不同的代码库。有些工件可在线免费提供，有些则为机密。（实际上，IDK 和操作系统二进制文件都有公开变体和机密变体。）
而将他们团结在一起的是：
- 它们全部完全基于 Fuchsia 源代码树的单个修订版本（具体而言，
integration.git2 的 Google 内部版本）构建而成，并且 - 它们会发布到同一发布版本下的相应代码库。
发布版本
发布版本是为发布版本命名的字符串。
每个发布版本在 Google 内部版本的 integration.git 中都有一个相应的标记，该标记不可变地指向构建发布版本的二进制工件的 git 提交。
版本命名为 M.YYYYMMDD.R.C（例如 2.20210213.2.5），其中
M表示此版本的“里程碑”。YYYYMMDD是版本的历史记录与main分支的差异的日期。R表示“发布”版本号。该值从 0 开始，如果同一日期创建了多个版本，则会递增。C表示“候选”版本号。此数量从 1 开始，在对里程碑版本分支中的上一个版本进行更改时递增。
Canary 版本
系统每天会创建几次 3 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 的可能性，因此与给定里程碑相关联的版本的可靠性和稳定性应该会随着时间的推移而提高。因此，我们建议下游客户尽快采用这些新的里程碑版本。
在某些特殊情况下，我们可能需要偏离这些政策（例如，可能需要在机密分支上开发安全修复程序，以避免在修复程序准备就绪之前将漏洞公开）。是否添加对里程碑版本分支的更改最终由版本管理员决定。
实现
本 RFC 不建议对 Fuchsia 发布流程进行任何更改。
向后兼容性
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 的大部分内容都将复制到单独的文档中，因此在 RFC 获得批准后，该文档还可以继续演变。
缺点、替代方案和未知情况
我们当前版本的命名方案并未明确区分 Canary 版本和里程碑版本。里程碑版本看起来就像是应用了许多精选的 Canary 版本。
版本号中出现的 YYYYMMDD 在软件中是非常唯一的，并且可能会具有误导性。偶尔的观察者可能会认为这是 build 或发布日期，其中较晚日期的 build “较新”，但对于里程碑版本来说，这种说法并不一定是正确的。在某些情况下，像 13.20230801... 这样的版本可能包含精选的修复程序，而 14.20230910... 中不包含此类修复程序。
我们可以改用更接近语义版本控制的版本命名方案，其中 Canary 版本用预发布标识符进行标记。
同样，“Canary”和“里程碑”这两个术语也是非标准术语。比较常见的一些术语可能是“预览版”和“稳定”。
从技术上讲，这些变更不会带来太大的困难，因此我们很可能希望在后续 RFC 中改进这些方面。
早期技术和参考资料
- Chromium 发布版本和版本号。
- semver.org