企业官网建设流程全解析

• 虚拟化
• 开发工具
• 云原生

Multipass 是 Canonical 出品的 Ubuntu 实例编排工具，其发布流程涵盖了特性发布（minor/major）、补丁发布（patch）、热修复合入、RC 候选迭代以及跨 Snap、GitHub、Microsoft Store 多渠道的最终发布。本篇基于仓库中的 dev-docs/release-process.md 官方发布流程文档，结合 src/cmake/versioning.cmake 等源码中的版本推导逻辑，完整还原一次 Multipass 版本从分支创建到公开宣布的全过程。读完本文，你将掌握如何创建 release 分支、打 RC 与正式签名 tag、通过 cherry-pick 将热修复合入补丁发布，以及如何协调 Snap 渠道提升、GitHub Draft Release 与 Windows 签名包签收等全链路操作。

前置约定：命令提示符与示例版本

原文档约定 Shell 命令使用branchname形式的提示符来标明命令执行所在的 git 分支上下文，例如main、release/1.15等。发布流程文档中的全部示例以发布1.15.0这一特性版本为贯穿案例：

• main提示符下的命令：在默认开发主干上执行；
• release/1.15提示符下的命令：在发布分支上执行；
• stable提示符下的命令：在稳定分支上执行（最终发布收尾阶段使用）。

实际发布时只需将示例中的1.15、1.15.0、1.16.0等版本号替换为目标版本即可。

发布类型总览：特性发布与补丁发布

Multipass 的发布分为两大类，流程的核心区别在于 RC 候选标签（tag）的命名方式：

• 特性发布（minor/major）：例如 1.15.0、1.16.0，携带新特性，需要从main上切出全新的release/X.Y分支；
• 补丁发布（patch）：例如 1.15.1、1.16.4，通常只包含热修复（hotfix），复用已有的特性分支而非新建分支。

发布节奏方面，根据 docs/reference/release-notes/index.md 的发布与支持策略：minor 版本大约每 6 个月发布一次，包含新特性与缺陷修复；patch 版本按需发布，包含关键缺陷修复与安全更新。同一时间通常只有最新版本处于活跃支持状态，用户被鼓励升级到最新版本以获取新特性、安全更新与缺陷修复。

特性发布（minor/major）

第一步：发布前的准备工作

1. 合并stable-docs分支到main。stable-docs承载着文档历史的持续演进，将其合并到main可以把任何分叉的文档改动带到未来的发布分支上，避免后续合入冲突；
2. 创建发布分支并打 RC 标签。注意 RC（Release Candidate，发布候选）现在也是带版本号的，例如rc1：

main $ git switch --create release/1.15 release/1.15 $ git push --set-upstream origin HEAD release/1.15 $ git tag v1.15.0-rc1 release/1.15 $ git push --tags

3. 为下一个版本创建开发提交并打 tag。在main上提交一个空提交作为 "Begin 1.16.0 development" 标记，并打上v1.16.0-dev的开发版本 tag：

main $ git commit --allow-empty --message 'Begin 1.16.0 development' main $ git push main $ git tag v1.16.0-dev main $ git push --tags

4. 在 GitHub 上发布 RC。

版本号的自动推导：源码视角

发布分支上的版本号并非手工填写，而是由 CMake 构建系统根据 git 描述自动推导，相关逻辑集中在 src/cmake/versioning.cmake 的determine_version()函数中：

• 构建系统首先执行git describe --long --abbrev=8获取带提交数的版本描述字符串；
• 通过is_release_branch()判断当前是否处于release/*分支（判定逻辑见 src/cmake/environment-utils.cmake：执行git describe --all --exact --match "${MULTIPASS_UPSTREAM_PREFIX}release/*"并匹配release/[0-9]+\.[0-9]+模式）；
• 只有release/*分支才会使用-rc标签——脚本注释明确写道 "only use -rc tags on release/* branches"；非发布分支则匹配*-dev标签；
• 在发布分支上构建时，必须设置MULTIPASS_UPSTREAM（以远端仓库为权威参考），否则会直接FATAL_ERROR提示 "You need to set MULTIPASS_UPSTREAM for a release build"；
• 若当前提交恰好命中正式发布 tag，则直接使用该精确标签作为版本号（git describe --exact），正式发布构建不携带特性开关后缀；
• 非精确命中时，版本号由GIT_TAG（-rc或-dev标签）+ 领先提交数 + 提交哈希构成，并追加特性开关后缀：默认完整特性构建为-noff（无特性标记），自定义特性集为-cstm，见 src/cmake/feature-flag.cmake 的调用；
• macOS 与 Windows 构建还会在版本号后追加+mac或+win后缀（若版本号已含+则改用.分隔符，以便 Windows VERSIONINFO 与 Flutter 构建号解析，参见determine_version_components()）。

由此可见，RC 标签v1.15.0-rc1之所以必须在发布分支上创建，正是为了让版本推导脚本能够识别并产出带-rc语义的候选版本号。

热修复（Hotfixes）

RC 创建之后，如果有热修复需要进入新的 RC，这些热修复必须首先合并进main，然后再把合并提交 cherry-pick 到发布分支之上。这是整个发布流程中保证主干与发布分支一致性的关键机制：

main $ git switch --create hotfix # Do hotfix work. hotfix $ git commit --message 'implemented hotfix' hotfix $ git push --set-upstream origin HEAD # Create a PR and merge into main when done. main $ git pull # Identify the merge commit(s) of the PRs that should be added to the release # For each commit: main $ git log # copy the hash of the hotfix merge commit release/1.15 $ git cherry-pick --mainline 1 <hotfix-merge-commit-hash> release/1.15 $ git push

要点说明：

• git cherry-pick --mainline 1用于挑选 PR 的合并提交（merge commit），--mainline 1指定以第一个父提交（即main上的主线）作为 diff 基准，从而只将 PR 引入的改动搬运到发布分支；
• 重复该流程，直到热修复集累积到满意的程度，再发布一个新的 RC；
• 从文档约定看，热修复在main与发布分支之间是"先主干、后分支"的单向流动，避免分支上出现主干没有的代码。

补丁发布（Patch releases）

补丁发布与特性发布的主要差异在于 RC 标签的命名方式（文档明确注明 "They differ from feature releases in tags for RCs"），以及不需要独立合并stable-docs分支：

• 不需要把stable-docs单独合并进main：新补丁发布会把它包含进来，并在未来合并回main；
• 复用已有的特性分支（例如用release/1.15来准备 1.15.x），而不是新建分支；
• 从maincherry-pick 提交到该分支之上；
• RC 标签按序递增：v1.15.1-rc1、v1.15.1-rc2……直到最终以签名标签v1.15.1发布。

仓库中 docs/reference/release-notes/ 目录下的 1.16.1、1.16.2、1.16.3、1.16.4 即为典型的补丁发布，例如 1.16.4.md 记录了"修复客户端/守护进程通信证书过期"这一补丁内容。

新的发布候选（RC）：特性与补丁通用

当一个特性或补丁发布被认为内容齐备后，就会构建并测试发布候选，直到其达到公开发布所需的稳定性。为新的 RC 打标签：

release/1.15 $ git tag v1.15.0-rc2 release/1.15 $ git push --tags

打完标签后，再次发布这个新 RC，并对其开展充分的测试。RC 迭代循环（打 tag → 发布 → 测试 → 打下一个 tag）会一直持续到候选版本达到可公开发布的质量门槛。

最终发布

当最新 RC 的状态令人满意后，就可以把它转正为正式发布。

准备发布

1. 在要发布的 RC 标签所在的同一提交上添加签名标签：

release/1.15 $ git tag --sign v1.15.0 --message 'Multipass version 1.15.0' release/1.15 $ git push --tags

2. 重启由发布分支触发的 GHA 运行（此处即release/1.15），使其在推导版本号时拾取新标签；
3. 从发布分支（而非 tag）触发的运行中获取 Windows/macOS 安装包。文档特别提醒：不要使用 tag 触发的产物，因为在当前时刻（ATTOW，at the time of writing）tag 触发的运行会产生错误的版本号；
4. 将 Windows/macOS 包送交 IS 签名，通常通过 Concordia 工单系统（concordia.canonical.com/tickets）发起；
5. 把最终的 Launchpad 构建提升到 beta 频道，在 Snapcraft 的 multipass 发布页（snapcraft.io/multipass/releases）操作：
   • 必要时先在 Launchpad 触发构建；
   • 务必选择 Launchpad 构建而非 GitHub 构建。Launchpad 构建在该页面会带有 "lp" 后缀，例如 "1.15.0 | lp-91234567"；该后缀并非实际版本号的一部分（已通过snap info和multipass version确认）；
6. 收到 IS 返回的签名包后验证签名：
   • macOS：pkgutil --check-signature <pkg>；
   • Windows：右键每个.exe，选择"属性"→"数字签名"面板（或使用 Microsoft 的 SignTool 工具验证文件签名）；
7. 在 GitHub 上创建草稿发布条目（draft release），附上已签名的 macOS 与 Windows 安装包；
8. 上传安装包到 Microsoft Store：
   • 将安装包放到一个公开、无重定向的 URL 下，例如 people.canonical.com 下的个人目录；
   • 登录 Microsoft Partner Center（partner.microsoft.com），进入 "Multipass > Packages" 上传安装包；
   • 对新安装包运行验证（validation），这可能需要数个工作日；
9. 向官方网站提交草稿 PR 以更新latest-release.json；
10. 准备发布说明与发布公告（面向 Discourse、Matrix、Mattermost）；
11. 向main提交一个 PR，包含：
    • 新版本发布说明，放入docs/reference/release-notes/目录；
    • 同步更新 index.md，添加指向新发布说明的链接，并补充/修改该发布内容的说明；
    • 遵循 发布说明模板，并将相同内容用于 GitHub 草稿发布。

公开发布

12. 将 Snap 从 beta 频道提升到 stable 频道；
13. 在 GitHub 上发布草稿；
14. 提交 Microsoft Store 更新；
15. 取消官方网站 PR 的草稿状态（标记为 "ready for review"）：
    • 发布公开后验证安装包链接可用；
    • 跟进该 PR 直至被合并；
16. 将stable分支指向该发布版本。这样 Launchpad 才能在 candidate 频道生成更新后的 Snap（携带更新的 deb 依赖）：Launchpad 每日检查 Snap 中是否存在过期的依赖，若有则会构建新包作为 candidate，验证通过后再提升到 stable：

stable $ git reset --hard release/1.15 stable $ git push --force

17. 合并发布说明文档 PR 到main；
18. 快进stable-docs分支指向该发布。这对应 ReadTheDocs 上展示的稳定版文档。由于stable-docs此前已合并进main，应无冲突；随后在stable-docs分支上 cherry-pick 发布说明 PR：

main $ git merge release/1.15 main $ git push

19. 将发布分支合并进main，用于跟踪两个版本之间的提交数量；
20. 确保发布分支（如release/1.15）保留在远端。如果存在对应 PR，GitHub 很可能在合并后自动删除该分支；若发生这种情况需要恢复它——Launchpad 上的候选构建依赖该分支来推导正确的版本号；
21. 在 Discourse、Matrix 和 Mattermost 上宣布新版本。

发布后数日内需跟进的事项

22. 验证 Microsoft Store 提交已获批（状态从 "in review" 移出）；
23. 确认官方网站上的最新版本 PR 已合并进 canonical.com；
24. 确认该发布版本的候选 Snap 已构建完成。

stable-docs与发布分支的关系

stable-docs分支的设计目标是在提交历史上始终与主干持平或领先，同时共享这段提交历史。这是因为文档每 24 小时就会从该分支生成一次，它必须同时包含历史变更与文档变更。该机制将"文档与源码之间可能的冲突"降到最低，同时把维护成本控制到最小：

• 特性发布前：将stable-docs合并到main，把文档改动带到发布分支；
• 最终发布后：快进stable-docs到发布提交，并 cherry-pick 发布说明 PR，使 ReadTheDocs 稳定版文档与发布版本对齐；
• 由于stable-docs一直与main共享提交历史，快进与 cherry-pick 通常不会产生冲突。

编写发布说明（Release Notes）

发布说明是最终发布环节的重要交付物。仓库提供了标准的模板文件 docs/reference/release-notes/release-notes-templates.md，其中规定了如下章节结构：

• 标题：# <Release version>，并附一段简短描述，说明是 minor 还是 patch 发布、突出本版的关键变化与主题；
• New features & improvements：以子章节形式列出新特性；
• Removed functionality：列出被移除的功能（包括长期处于弃用路径上、在本版移除的功能）；
• Deprecations：列出弃用功能，并尽量给出替代方案；
• Known issues：列出已知问题及修复计划（如有）；
• Bug fixes：用 1–2 行描述每个缺陷修复，尽量附带相关 PR/issue 链接；
• New contributors：致谢新贡献者，包含 GitHub 账号与首次贡献链接；
• Feedback：引导用户通过 GitHub issues、Discourse 论坛与 Matrix 房间反馈问题。

仓库中已有的发布说明即为模板的实际应用范例：例如 1.16.0.md 展示了特性发布的写法（"Fully open source"、"Custom image launch"、GUI 改进、弃用说明、缺陷修复与新贡献者列表等），而 1.16.4.md 则展示了补丁发布的精简写法（通常只包含 Bug fixes 与指向完整 diff 的引用）。所有发布说明的汇总入口在 index.md，该文件维护"发布日期 ↔ 发布说明"对照表，并概述当前 minor 系列（如 1.16.x）的改进要点，是每次发布必须同步更新的文档。

发布流程中的关键注意事项汇总

• RC 标签的命名：特性发布用vX.Y.0-rcN且需新建发布分支；补丁发布用vX.Y.Z-rcN且复用已有特性分支；只有release/*分支上的构建才会被版本推导脚本识别为 RC 语义（见 versioning.cmake 与 environment-utils.cmake）；
• 热修复必须"先入 main，再 cherry-pick 到发布分支"，保证主干与发布分支的代码一致性；
• 正式发布 tag 必须签名（git tag --sign），而 RC 与 dev tag 无需签名；
• 发布产物的版本号来源：Windows/macOS 安装包应取自发布分支触发的 GHA 运行，而非 tag 触发的运行；Snap 的渠道提升则务必选择带 "lp" 后缀的 Launchpad 构建；
• stable分支、stable-docs分支与main的收敛顺序：先stable指向发布（驱动 Launchpad 候选构建），再合并文档 PR、快进stable-docs，最后将发布分支合并回main，并确保发布分支在远端保留（Launchpad 候选构建依赖它推导版本）；
• 多渠道协同：一次公开发布同时涉及 Snap（beta → stable）、GitHub（草稿 → 公开）、Microsoft Store（上传 → 验证 → 提交 → 获批）、官方网站（latest-release.jsonPR）与社区公告（Discourse / Matrix / Mattermost）。

以上流程以仓库中的 dev-docs/release-process.md 为骨架，其背后的版本自动推导、发布分支判定等机制可在 src/cmake/versioning.cmake 与 src/cmake/environment-utils.cmake 中进一步查验。若需了解发布产物的实际装配方式，可继续阅读 packaging/ 目录下的 Snap、Windows 与 macOS 打包配置。

• 虚拟化
• 开发工具
• 云原生