| 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
Reviewers:
- billstevenson@google.com，版本计划管理主管
- abarth@google.com，相关 RFC-0002 的作者
- atyfto@google.com，共同作者和基础架构负责人
咨询者：aaronwood@google.com、chaselatta@google.com、sethladd@google.com
社交化：与专家协商，确保其准确反映了世界当前的状况。
要求
此 RFC 介绍了当前的发布流程。它不会规定任何更改。
如上所述，此 RFC 不讨论向最终用户分发软件。此 RFC 中介绍的工件会交付给开发者和产品所有者。他们使用这些工件构建软件，最终通过超出本 RFC 范围的流程将软件交付给最终用户。
设计
Fuchsia release 是一组生成的工件，是 Fuchsia 项目在给定时间点的输出，以特定的版本名称发布。
它由以下部分组成：
- 集成开发套件 (IDK)：一小组库、软件包和工具，用于构建和运行以 Fuchsia 为目标平台的程序。
- 基于 IDK 的多个 SDK（例如 Bazel SDK）。
- 操作系统 (OS) 二进制文件，包括内核、引导加载程序、软件包、工具以及配置和组装 Fuchsia 产品软件包所需的其他组件。
- 各种其他工件，例如文档和 Fuchsia 兼容性测试 (CTF) build。
没有任何单个归档文件包含所有这些工件；不同的构建器会生成不同的工件，并上传到不同的代码库。有些工件可在网上免费获取，有些工件则是机密的。（事实上，IDK 和操作系统二进制文件都具有公开和机密变体。）
它们的共同点在于：
- 它们全部仅基于 Fuchsia 源代码树的单个修订版本（具体而言，是
integration.git2 的 Google 内部版本）构建而成，并且 - 它们都发布到各自的代码库，并采用相同的发布版本。
发布版本
发布版本是用于命名发布版本的一串字符。
每个发布版本在 Google 内部版本的 integration.git 中都有对应的标记，该标记会永久指向用于构建该版本二进制工件的 git 提交。
版本的命名方式为 M.YYYYMMDD.R.C（例如 2.20210213.2.5），其中
M表示版本的“里程碑”。YYYYMMDD是相应版本的历史记录与main分支分歧的日期。R表示“release”版本号。版本号从 0 开始，如果同一天创建多个版本，则版本号会递增。C表示“候选”版本号。该版本号从 1 开始，当对里程碑版本分支上的上一个版本进行更改时，该版本号会递增。
Canary 版本
系统每天会创建几次 Canary 版本3，具体取决于 Fuchsia 源代码树的最新已知良好修订版。具体而言，系统会将 git 标记应用于 Google 内部版本的 integration.git 中的相应修订版，并触发各种构建器来构建和发布上述工件。Canary 版本没有自己的版本分支，只有标记。
每个 Canary 版仅在短时间内受支持，即在下一个 Canary 版发布之前。我们不会挑选 bug 修复程序并将其添加到 Canary 版本中。（换句话说：Canary 版本的“候选”版本号始终应为“1”。）如果在 Canary 版本中发现 bug，系统会将相应 bug 的修复程序应用于 Fuchsia 源代码树的 main 分支。受该 bug 影响的客户端应回滚到较低版本，并/或等待包含修复程序的后续 Canary 版本。
因此，Canary 版本适用于开发和测试，但可能不适用于生产环境。对于生产用例，最好使用里程碑版本。
里程碑版本
每隔几周，Google 内部版本和 integration.git 的公共镜像中都会创建一个里程碑版本分支，从现有“已知良好”的 Canary 版本的 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 和 Milestone 这些术语也不是标准术语。比较常见且有点类似的术语可能是预览版和稳定版。
从技术层面讲，这些更改并不难做，因此我们可能需要在后续的 RFC 中改进这些内容。
在先技术和参考文档
- Chromium 发布渠道和版本号。
- semver.org