虚拟化开发工具云原生【免费下载链接】multipassMultipass orchestrates virtual Ubuntu instances项目地址https://gitcode.com/gh_mirrors/mu/multipass点击查看免费下载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第一步发布前的准备工作合并stable-docs分支到main。stable-docs承载着文档历史的持续演进将其合并到main可以把任何分叉的文档改动带到未来的发布分支上避免后续合入冲突创建发布分支并打 RC 标签。注意 RCRelease Candidate发布候选现在也是带版本号的例如rc1main $ 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为下一个版本创建开发提交并打 tag。在main上提交一个空提交作为 Begin 1.16.0 development 标记并打上v1.16.0-dev的开发版本 tagmain $ git commit --allow-empty --message Begin 1.16.0 development main $ git push main $ git tag v1.16.0-dev main $ git push --tags在 GitHub 上发布 RC。版本号的自动推导源码视角发布分支上的版本号并非手工填写而是由 CMake 构建系统根据 git 描述自动推导相关逻辑集中在 src/cmake/versioning.cmake 的determine_version()函数中构建系统首先执行git describe --long --abbrev8获取带提交数的版本描述字符串通过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语义的候选版本号。热修复HotfixesRC 创建之后如果有热修复需要进入新的 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 的状态令人满意后就可以把它转正为正式发布。准备发布在要发布的 RC 标签所在的同一提交上添加签名标签release/1.15 $ git tag --sign v1.15.0 --message Multipass version 1.15.0 release/1.15 $ git push --tags重启由发布分支触发的 GHA 运行此处即release/1.15使其在推导版本号时拾取新标签从发布分支而非 tag触发的运行中获取 Windows/macOS 安装包。文档特别提醒不要使用 tag 触发的产物因为在当前时刻ATTOWat the time of writingtag 触发的运行会产生错误的版本号将 Windows/macOS 包送交 IS 签名通常通过 Concordia 工单系统concordia.canonical.com/tickets发起把最终的 Launchpad 构建提升到 beta 频道在 Snapcraft 的 multipass 发布页snapcraft.io/multipass/releases操作必要时先在 Launchpad 触发构建务必选择 Launchpad 构建而非 GitHub 构建。Launchpad 构建在该页面会带有 lp 后缀例如 1.15.0 | lp-91234567该后缀并非实际版本号的一部分已通过snap info和multipass version确认收到 IS 返回的签名包后验证签名macOSpkgutil --check-signature pkgWindows右键每个.exe选择属性→数字签名面板或使用 Microsoft 的 SignTool 工具验证文件签名在 GitHub 上创建草稿发布条目draft release附上已签名的 macOS 与 Windows 安装包上传安装包到 Microsoft Store将安装包放到一个公开、无重定向的 URL 下例如 people.canonical.com 下的个人目录登录 Microsoft Partner Centerpartner.microsoft.com进入 Multipass Packages 上传安装包对新安装包运行验证validation这可能需要数个工作日向官方网站提交草稿 PR 以更新latest-release.json准备发布说明与发布公告面向 Discourse、Matrix、Mattermost向main提交一个 PR包含新版本发布说明放入docs/reference/release-notes/目录同步更新 index.md添加指向新发布说明的链接并补充/修改该发布内容的说明遵循 发布说明模板并将相同内容用于 GitHub 草稿发布。公开发布将 Snap 从 beta 频道提升到 stable 频道在 GitHub 上发布草稿提交 Microsoft Store 更新取消官方网站 PR 的草稿状态标记为 ready for review发布公开后验证安装包链接可用跟进该 PR 直至被合并将stable分支指向该发布版本。这样 Launchpad 才能在 candidate 频道生成更新后的 Snap携带更新的 deb 依赖Launchpad 每日检查 Snap 中是否存在过期的依赖若有则会构建新包作为 candidate验证通过后再提升到 stablestable $ git reset --hard release/1.15 stable $ git push --force合并发布说明文档 PR 到main快进stable-docs分支指向该发布。这对应 ReadTheDocs 上展示的稳定版文档。由于stable-docs此前已合并进main应无冲突随后在stable-docs分支上 cherry-pick 发布说明 PRmain $ git merge release/1.15 main $ git push将发布分支合并进main用于跟踪两个版本之间的提交数量确保发布分支如release/1.15保留在远端。如果存在对应 PRGitHub 很可能在合并后自动删除该分支若发生这种情况需要恢复它——Launchpad 上的候选构建依赖该分支来推导正确的版本号在 Discourse、Matrix 和 Mattermost 上宣布新版本。发布后数日内需跟进的事项验证 Microsoft Store 提交已获批状态从 in review 移出确认官方网站上的最新版本 PR 已合并进 canonical.com确认该发布版本的候选 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 候选构建依赖它推导版本多渠道协同一次公开发布同时涉及 Snapbeta → 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 打包配置。赞分享虚拟化开发工具云原生【免费下载链接】multipassMultipass orchestrates virtual Ubuntu instances项目地址https://gitcode.com/gh_mirrors/mu/multipass点击查看免费下载相关推荐react-native-macos 版本发布指南Release Train 分支、RC 候选版与 Stable 稳定版全流程react native macos 版本发布指南Release Train 分支、RC 候选版与 Stable 稳定版全流程 导读 本文基于仓库根目录的 R桌面应用跨平台Genkit Python SDK 版本发布全流程实战指南从 RC 候选版到 PyPI 稳定发布Genkit Python SDK 版本发布全流程实战指南从 RC 候选版到 PyPI 稳定发布 导读 本文围绕 Genkit 开源仓库中 Python 发布人工智能大模型后端AI AgentRAG工具调用Velero 版本发布全流程指南从 RC 到 GA 的完整发布操作手册Velero 版本发布全流程指南从 RC 到 GA 的完整发布操作手册 本篇指南完整讲解 Velero 项目的版本发布流程从版本类型定义、发布候选RC与云原生灾备存储后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
