| 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
审核者：
- billstevenson@google.com，发布计划管理主管
- 相关 RFC-0002 的作者 abarth@google.com
- 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。
没有包含所有这些制品的一个归档；不同的制品由不同的构建器生成，并上传到不同的代码库。有些制品可在网上免费获取，有些则属于机密制品。（事实上，IDK 和操作系统二进制文件都有公开变体和保密变体。）
它们的共同点在于：
- 它们全部仅基于 Fuchsia 源代码树的单个修订版本（具体而言，是
integration.git2 的 Google 内部版本）构建，并且 - 它们都发布到各自代码库中的同一发布版本下。
发布版本
发布版本是用于命名发布的字符串。
每个发布版本在 integration.git 的 Google 内部版本中都有一个对应的标记，该标记不可变地指向用于构建相应发布版本的二进制工件的 Git 提交。
版本命名为 M.YYYYMMDD.R.C（例如 2.20210213.2.5），其中
M表示发布版本的“里程碑”。YYYYMMDD是相应版本的历史记录与main分支发生分歧的日期。R表示“发布”版本号。它从 0 开始，并在同一日期创建多个版本时递增。C表示“候选”版本号。它从 1 开始，当对里程碑版本分支上的先前版本进行更改时，该值会递增。
Canary 版本
每天会创建几次3 Canary 版本，该版本基于 Fuchsia 源代码树的最新已知良好修订版本。具体而言，系统会在 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 开头，如下图所示：
里程碑版本与其所基于的金丝雀版本共享版本号的 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 版和里程碑版。里程碑版本看起来就像应用了大量 Cherry-pick 的 Canary 版本。
版本号中存在 YYYYMMDD 在软件中相当独特，可能会造成误导。普通观察者可能会认为这是 build 或发布日期，日期较晚的 build 是“较新”的，但对于里程碑版本而言，这不一定正确。在某些情况下，13.20230801... 等版本可能包含 14.20230910... 不包含的精选修复。
我们可以改用更接近语义版本控制的版本命名方案，并使用预发布版本标识符来标记 Canary 版。
同样，canary 和 milestone 这两个术语也属于非标准术语。一些较为类似且更常用的术语可能是预览版和稳定版。
从技术上讲，这些更改并不难实现，因此我们很可能会在后续 RFC 中改进这些方面。
在先技术和参考资料
- Chromium 发布渠道和版本号。
- semver.org