Wasmtime 发布流程全解析月度主版本、补丁发布与自动化发布机制的完整指南【免费下载链接】wasmtimeA lightweight WebAssembly runtime that is fast, secure, and standards-compliant项目地址: https://gitcode.com/gh_mirrors/wa/wasmtime本文基于仓库文档 docs/contributing-release-process.md 编写面向 Wasmtime 的维护者以及所有对 Wasmtime 发布机制感兴趣的开发者完整梳理从版本号生命周期、月度主版本发布、补丁发布到安全补丁发布的全部流程并结合仓库中的 GitHub Actions 工作流与wasmtime-publish工具源码深入讲解发布自动化背后的实现原理。读完本文你将掌握 Wasmtime 的发布节奏、每个自动生成的 PR 背后的含义以及维护者需要人工介入的所有关键节点。Wasmtime 的发布流程由docs/contributing-release-process.md定义并驱动它既是一份给维护者使用的内部检查清单也是一份对外公开的流程文档。该文档与 docs/stability-release.md发布策略总览、docs/security-vulnerability-runbook.md安全漏洞响应手册相互补充共同构成 Wasmtime 版本治理的完整体系。本文将以该文档为主线逐条展开其背后由 CI 与工具代码落实的每一个步骤。版本号生命周期从-dev到正式发布理解 Wasmtime 发布流程的第一步是掌握版本号在整个流程中的演变规律。文档明确指出Wasmtime 的版本号会经历三个阶段main分支永久携带X.Y.Z-dev版本号。这个版本永远不会被发布到任何地方它的存在只是为了让人一眼看出当前 checkout 的main处于开发状态。发布分支被创建后版本号变为X.Y.Z-rc.1随后以 pre-release预发布的形式发布到 crates.io 和 GitHub Releases。如果后续还需要更多验证可以继续推进到-rc.2、-rc.3等。正式发布日-rc.N后缀被去掉X.Y.Z作为正式版本发布。这一开发版 → 候选版 → 正式版的三段式生命周期配合每月 5 日切分支、每月 20 日正式发布的固定节奏保证了每个版本从main上的开发完成到最终发布之间至少有约两周的冷却期用于对main上的变更进行 fuzz 测试并给使用main的早期用户留出测试窗口。从源码层面看版本号的读取由一个简单的脚本完成ci/print-current-version.sh 通过grep ^version Cargo.toml | head -n 1 | sed s/.*\(.*\)/\1/从根Cargo.toml的[workspace.package] version字段中提取当前工作区版本发布工作流中的所有版本判断都依赖它。月度主版本发布每月两次的自动化流水线Wasmtime 的主版本发布遵循每月一次、高度自动化的原则。文档给出了高层概述每月 5 日基于main的当前内容创建新的release-X.Y.Z分支并发布X.Y.Z-rc.1作为首个发布候选。每月 20 日将该发布分支发布到 crates.io并构建发布产物。这意味着 Wasmtime 的正式发布总是比main上的开发进度落后至少两周并且每月只发布一次。文档也明确说明大多数消费者应当使用发布分支而非main。完整的自动化步骤17文档以编号清单的形式详细列出了整个流程。其中需要人类维护者介入的步骤用加粗标注其余步骤全部由自动化完成。以下是对原文步骤的完整展开每月 5 日CI 任务自动执行由.github/workflows/release-process.yml配置下载当前main分支将main推送到release-X.0.0分支运行wasmtime-publishcrate 的bump-major参数提交变更将变更推送到一个临时的ci/*分支向main打开一个 PR然后从切出发布分支的那个 commit 重新开始运行wasmtime-publish的bump-rc参数将版本推进到X.0.0-rc.1在 commit message 中加入tag-and-release 标记并向release-X.0.0打开第二个 PR该步骤也可以通过工作流的手动触发workflow_dispatch配合main分支和cut参数来执行。一名 Wasmtime 维护者合并这两个 PR这两个 PR 只是版本号提升因此可以立即合并。合并发布分支的那个 PR 会以与正式发布相同的打 tag 发布路径发布X.0.0-rc.1区别仅在于 GitHub Release 被标记为 pre-release。时间推移release-X.0.0分支持续维护所有变更先落在main上再按需 backport 到release-X.0.0。如果累积的变更足够多、值得再次测试可以手动触发选择发布分支 release-rc参数发布下一个-rc.N合并对应 PR 后新候选发布前一个候选被 yank撤回。每月 20 日另一个 CI 任务执行Reset 到release-X.0.0运行wasmtime-publish的bump-drop-rc参数去掉-rc.N后缀使版本定格在X.0.0在RELEASES.md中将X.0.0的发布日期更新为今天在 commit message 中加入特殊标记表明应该创建 tag针对release-X.0.0打开一个 PR该步骤同样可以手动触发main分支 release-latest参数。一名维护者合并该 PR合并时由于 commit message 中的标记会触发后续步骤。维护者应再次确认[没有未解决的 RUSTSEC 安全问题]但其他发布相关问题此时应已全部解决。主 CI 工作流.github/workflows/main.yml的收尾特殊逻辑对release-*分支的推送会扫描被推送变更的 git log查找release-process.yml添加的特殊标记。如果找到标记且 CI 全部通过就创建并推送 tag。tag 创建后.github/workflows/publish-*工作流运行其中一个将所有 crate 原样发布到 crates.io另一个下载main.yml工作流的所有构建产物并将它们作为官方 release 上传。文档总结道如果一切顺利维护者几乎不需要阅读太多说明——只需要为自动生成的 PR 按下大绿按钮Big Green Button剩下的都会自动完成。源码视角release-process.yml工作流的关键实现在仓库的 .github/workflows/release-process.yml 中上述步骤以真实代码的形式落地其设计要点包括定时调度on.schedule配置了0 0 5 * *和0 0 20 * *两个 cron 表达式分别对应每月 5 日和 20 日的零点。手动触发workflow_dispatch暴露action输入可选值为cut、release-latest、release-rc、release-patch默认cut。分支切分逻辑通过cur_dev$(./ci/print-current-version.sh)获取当前-dev版本cur${cur_dev%-dev}去掉后缀得到即将发布的版本branchrelease-${cur_dev%-dev}构造分支名随后git push origin HEAD:$branch直接推送创建发布分支——这是文档中所说的脚本直接执行的写操作其他步骤则尽量通过 PR 交由人类审查。版本提升与发布说明整理切出分支后执行cargo run -p wasmtime-publish bump-major提升main上的版本随后用sed -i 0,/-----------/d RELEASES.md删除当前版本的发布说明将历史版本归档条目追加到ARCHIVE_START标记之后并用sed s/VERSION/$num/ ci/RELEASES-template.md RELEASES.md以模板重建新的发布说明文件。cargo vet 同步每次版本提升后都会运行cargo vet为新 crate 版本更新供应链审查条目。PR 自动创建工作流通过gh pr create向main版本提升 PR和release-X.Y.Z发布候选 PR分别发起 PR并在 PR 正文中说明用途。关键提交标记发布候选和正式发布的 commit message 都包含一行[automatically-tag-and-release-this-commit]这是后续触发打 tag 的暗号。正式发布准备release-latest分支执行bump-drop-rc去掉候选后缀并用sed -i s/^Unreleased/Released $(date %Y-%m-%d)/ RELEASES.md把Unreleased替换为实际发布日期。tag 的触发与创建机制文档第 6 步提到的特殊逻辑位于 .github/workflows/main.yml 的push-tagjob 中约第 1558 行起。该 job 只在release-*分支的 push 事件且全部 CI 成功后运行它会执行git log ${{ github.event.before }}...${{ github.event.after }} | tee main.log version$(grep ^version Cargo.toml | head -n 1 | sed s/.*\(.*\)/\1/) if grep -q automatically-tag-and-release-this-commit main.log; then echo push_tagyes fi即扫描 push 前后的 commit 历史若发现标记字符串则通过 GitHub API 创建refs/tags/vX.Y.Z。注释还解释了这样设计的原因通过 API 创建 tag 可以确保 tag 本身再次触发 CI从而驱动完整的发布流程同时push-tag依赖ci-statusjob保证 tag 只在构建产物上传完成之后创建因为后续的publish-artifacts.yml需要下载这些产物。发布产物与 crates.io 发布tag 创建后有两个publish-*工作流接力.github/workflows/publish-to-cratesio.yml 监听v*tag 的 push依次运行cargo run -p wasmtime-publish publish和cargo run -p wasmtime-publish yank-old-rcs并使用rust-lang/crates-io-auth-action完成 crates.io 认证随后还会构建并发布wasi-preview1-component-adapter-providercrate。.github/workflows/publish-artifacts.yml 下载main.yml工作流产生的构建产物通过./ci/merge-artifacts.sh合并生成 GitHub Releasemain分支的产物作为devpre-release 上传发布分支的产物则作为正式 release分支名含-时标记为 pre-release并取RELEASES.md中分隔线之前的内容作为 release notes。wasmtime-publish工具版本提升与发布的执行核心文档中反复提到的wasmtime-publishcrate 位于 crates/misc/publish/src/main.rs。它的文件头注释直接引用了本文所讲的文档并列出全部命令参数命令作用cargo run -p wasmtime-publish bump-major将所有 crate 版本提升到下一个-devcargo run -p wasmtime-publish bump-patch提升 patch 版本号cargo run -p wasmtime-publish bump-rc推进到下一个 release candidatecargo run -p wasmtime-publish bump-drop-rc去掉 pre-release 后缀cargo run -p wasmtime-publish verify验证 crate 可以发布到 crates.iocargo run -p wasmtime-publish publish实际发布 crate 到 crates.iocargo run -p wasmtime-publish yank-old-rcsyank 被取代的 release candidatecargo run -p wasmtime-publish latest-release打印最近一个 release 分支的版本号从源码结构看该工具在启动时会扫描crates、cranelift、pulley、winch四个目录下的所有Cargo.tomlfind_crates递归遍历读取每个 crate 的版本和publish标志默认true再按照CRATES_TO_PUBLISH定义的拓扑顺序排序后执行相应操作。CRATES_TO_PUBLISH拓扑排序的发布清单源码中CRATES_TO_PUBLISH数组按依赖关系拓扑排序覆盖了 Wasmtime 工作区中所有需要发布的一方才 crate从wasmtime-internal-core、cranelift-bitset开始依次是 pulleypulley-macros、pulley-interpreter、cranelift 全家cranelift-srcgen、cranelift-codegen、cranelift-frontend等、wiggle、wasmtime 本体及所有wasmtime-wasi-*系列、wasmtime-cli等约 65 个 crate。工具源码中的断言强制约束任何设置了publish true的 crate 必须出现在该列表中否则构建即报错——这保证了发布范围是显式、可审查的。PUBLIC_CRATES补丁发布的红线清单PUBLIC_CRATES数组列出了补丁发布中不允许发生 semver API 破坏的 crate包括wasmtime、wasmtime-wasi、wasmtime-wasi-http、wasmtime-cli、wasmtime-wizer以及所有 cranelift crate含wasmtime-types。与之相对的规则是不在该列表中的 crate 必须使用a.b.c的精确版本依赖从而允许在补丁版本中对其内部 API 进行破坏性修改——因为它们只是组织内部细节外部不应依赖。这一约束在bump_version函数中有具体实现遍历每个 manifest 的所有依赖表dependencies、dev-dependencies、build-dependencies、[workspace.dependencies]以及平台相关的[target.cfg(..).dependencies]对第一方才 crate 的依赖若依赖的是PUBLIC_CRATES中的 crate则必须使用 caret^宽松版本约束若依赖的是内部 crate则必须使用精确锁定。发布重试与 C API 版本同步源码还体现了发布大型多 crate 工作区时的工程细节publish命令会在一个最多 10 次的循环中反复尝试发布每次剔除已成功的 crate失败的 crate 等待 40 秒后重试以应对 crates.io 的限流和索引传播延迟全部成功后工具会提示手动推送vX.Y.Ztag。此外bump-*系列命令都会调用update_capi_version()同步更新 crates/c-api/include/wasmtime.h 中的版本宏——WASMTIME_VERSION字符串携带完整版本含 pre-release 后缀而数字宏只包含major.minor.patch三元组。补丁版本发布按需进行、人工介入更多Wasmtime 目前没有补丁版本的固定节奏或严格标准属于按需发布。但文档明确列出了硬性要求所有变更必须先落在main上如适用再 backport 到较旧的分支发布分支应已通过上述主版本流程存在。补丁发布必须应用到所有需要该补丁的受支持版本受支持版本清单见 docs/stability-release.md#current-versions。Wasmtime 不会在某个版本尚未同步打补丁时单独发布以保证各版本发布的一致性。补丁发布不得包含公共 crate 的 API 破坏性变更需要关注的是crates/misc/publish/src/main.rs中的PUBLIC_CRATES列表。默认不允许 Wasm 层面的 ABI 破坏性变更。例如用户应当能够加载补丁发布之前生成的*.cwasm产物。如果确实需要 ABI 破坏性变更必须更新 crates/wasmtime/src/engine/serialization.rs 中的WasmtimeVersion匹配策略修改版本字符串以确保旧产物无法被加载。关于第 4 点可以从源码中找到佐证crates/wasmtime/src/engine/serialization.rs 中ModuleVersionStrategy::WasmtimeVersion第 835 行附近正是将当前 Wasmtime 版本号编码进序列化模块产物的默认策略——Wasmtime 的序列化格式中携带版本信息加载*.cwasm时据此判断兼容性。以 2.0.1 为例的补丁发布步骤文档以2.0.1为例给出了补丁发布的操作清单人工介入步骤用加粗标注必要变更从mainbackport 到release-2.0.0分支受支持分支的 CI 在发布后仍每周运行以确保分支最多坏一周但仍需注意main上 CI 绿不代表 release 分支也绿。合并 backport 时维护者需要双重确认crates/misc/publish/src/main.rs中的PUBLIC_CRATES没有发生最严格意义上的semver API 破坏所有安全修复都必须以不破坏 API 的方式完成。别忘了在RELEASES.md中为 backport 的变更写补丁说明patch notes。手动触发补丁发布流程在 CI 的 release-process 工作流中选择release-2.0.0分支和release-patch参数。wasmtime-publish会以bump-patch参数运行变更提交时携带需要发布的特殊标记并从临时ci/*分支向release-2.0.0创建 PR——合并该 PR 即触发发布流程。审查生成的 PR 并合并这一步会接续主版本流程中的第 6 步——commit message 中由 CI 生成的特殊标记触发 tag 推送进而触发后续发布流程。合并前请确保此时已将RELEASES.md中的Released on日期直接 push 到与 PR 关联的分支上。上述步骤在工作流源码中对应release-patch分支.github/workflows/release-process.yml 第 230 行起执行bump-patch、运行cargo vet、用sed把Unreleased替换为发布日期最后以包含[automatically-tag-and-release-this-commit]标记的 commit 创建 PR。补丁发布相关的策略背景值得补充的是docs/stability-release.md 进一步界定了补丁发布的适用范围补丁版本只用于受支持版本中默认开启行为的安全问题与关键正确性问题修复并保证 API 与行为向后兼容、升级简单。例如当前版本为39.0.0时安全问题会同时发布39.0.x、38.0.x、36.0.x当前 LTS和24.0.x上一 LTS四个补丁版本。此外Cranelift 发现的任何 miscompilation 都会促成补丁发布且由于当前发布流程的耦合Cranelift 的补丁发布会连带触发 Wasmtime 的补丁发布。安全补丁发布对于安全相关的发布本文所依托的文档明确指向了专门的漏洞响应手册docs/security-vulnerability-runbook.md。安全修复遵循与普通 backport 相同的流程但区别在于发布日前会在私有环境中协调。维护者在执行正式发布前的最后一步时应当检查没有未解决的安全问题再合并触发发布的 PR。发布说明Release Notes管理Wasmtime 的发布说明写在仓库根目录的 RELEASES.md 中文档说明了其管理方式理论上main上的所有变更都应附带对RELEASES.md的相应更新但实践中几乎从未做到。当main分支版本号提升时RELEASES.md会被清空替换为 ci/RELEASES-template.md并在底部的版本列表中加入即将发布版本的条目。现实情况是release-X.Y.Z分支创建后发布说明直接在发布分支上更新和编辑。从模板文件 ci/RELEASES-template.md 可以看到其内容是一个以## VERSION开头的骨架包含Unreleased.占位、### Added与### Changed小节以及一条分隔线工作流通过sed s/VERSION/$num/将VERSION替换为真实版本号再追加历史归档内容。由于上述机制RELEASES.md只包含当前所在分支的发布说明历史版本说明通过文件底部的链接指向旧版RELEASES.md归档。需要注意的是main分支的版本提升会触发RELEASES.md的重置删除当前版本内容、插入归档条目这正是 .github/workflows/release-process.yml 中sed -i 0,/-----------/d RELEASES.md与ARCHIVE_START追加逻辑的职责。保持旧发布分支的 CI 可用随着时间推移CI 配置会逐渐过时。Wasmtime 仓库通过 GitHub Actions 的 cron job每周在所有受支持的发布分支上运行一次发布 CI以尽早发现此类问题。如果某个发布分支的 CI 失败会自动开 issue维护者需要尽快解决。文档还给出了一条务实的原则尽量不通过升级软件来修复旧分支的 CI对于此前未固定的依赖尽量固定到较旧版本。当然有时升级不可避免那就必须升级。维护者操作速查综合文档全文以下操作节点需要维护者人工介入值得作为速查清单保存时机操作触发方式每月 5 日或手动cut合并两个自动生成的 PRmain版本提升 PR release-X.Y.Z的-rc.1发布 PR自动生成人工合并需要更多验证时以release-rc手动触发合并生成的候选发布 PR手动触发每月 20 日或手动release-latest确认无未解决安全问题、RELEASES.md内容正确后合并正式发布 PR自动生成人工合并需要补丁发布时先 backport 到发布分支并写 patch notes再以release-patch触发合并生成的 PR手动触发每周检查发布分支的每周 CI若失败则尽快修复cron 自动运行结语Wasmtime 的发布流程是策略文档 自动化工作流 专用工具三者协同的典型范例docs/contributing-release-process.md定义流程与人工介入点.github/workflows/release-process.yml 负责每月两次的定时切分支、版本提升与 PR 创建crates/misc/publish/src/main.rs 中的wasmtime-publish工具承担版本改写、依赖约束校验与 crates.io 发布而 .github/workflows/main.yml 的push-tagjob 与两个publish-*工作流则在标记的驱动下完成打 tag、发布 crate 与上传产物。理解这条链路后无论是作为维护者执行一次发布还是作为使用者追踪某个版本的来历都能快速定位到对应的代码与文档位置。对于发布节奏、受支持版本与候选版保障等策略层面的问题可进一步阅读 docs/stability-release.md。【免费下载链接】wasmtimeA lightweight WebAssembly runtime that is fast, secure, and standards-compliant项目地址: https://gitcode.com/gh_mirrors/wa/wasmtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Wasmtime 发布流程全解析：月度主版本、补丁发布与自动化发布机制的完整指南
Wasmtime 发布流程全解析月度主版本、补丁发布与自动化发布机制的完整指南【免费下载链接】wasmtimeA lightweight WebAssembly runtime that is fast, secure, and standards-compliant项目地址: https://gitcode.com/gh_mirrors/wa/wasmtime本文基于仓库文档 docs/contributing-release-process.md 编写面向 Wasmtime 的维护者以及所有对 Wasmtime 发布机制感兴趣的开发者完整梳理从版本号生命周期、月度主版本发布、补丁发布到安全补丁发布的全部流程并结合仓库中的 GitHub Actions 工作流与wasmtime-publish工具源码深入讲解发布自动化背后的实现原理。读完本文你将掌握 Wasmtime 的发布节奏、每个自动生成的 PR 背后的含义以及维护者需要人工介入的所有关键节点。Wasmtime 的发布流程由docs/contributing-release-process.md定义并驱动它既是一份给维护者使用的内部检查清单也是一份对外公开的流程文档。该文档与 docs/stability-release.md发布策略总览、docs/security-vulnerability-runbook.md安全漏洞响应手册相互补充共同构成 Wasmtime 版本治理的完整体系。本文将以该文档为主线逐条展开其背后由 CI 与工具代码落实的每一个步骤。版本号生命周期从-dev到正式发布理解 Wasmtime 发布流程的第一步是掌握版本号在整个流程中的演变规律。文档明确指出Wasmtime 的版本号会经历三个阶段main分支永久携带X.Y.Z-dev版本号。这个版本永远不会被发布到任何地方它的存在只是为了让人一眼看出当前 checkout 的main处于开发状态。发布分支被创建后版本号变为X.Y.Z-rc.1随后以 pre-release预发布的形式发布到 crates.io 和 GitHub Releases。如果后续还需要更多验证可以继续推进到-rc.2、-rc.3等。正式发布日-rc.N后缀被去掉X.Y.Z作为正式版本发布。这一开发版 → 候选版 → 正式版的三段式生命周期配合每月 5 日切分支、每月 20 日正式发布的固定节奏保证了每个版本从main上的开发完成到最终发布之间至少有约两周的冷却期用于对main上的变更进行 fuzz 测试并给使用main的早期用户留出测试窗口。从源码层面看版本号的读取由一个简单的脚本完成ci/print-current-version.sh 通过grep ^version Cargo.toml | head -n 1 | sed s/.*\(.*\)/\1/从根Cargo.toml的[workspace.package] version字段中提取当前工作区版本发布工作流中的所有版本判断都依赖它。月度主版本发布每月两次的自动化流水线Wasmtime 的主版本发布遵循每月一次、高度自动化的原则。文档给出了高层概述每月 5 日基于main的当前内容创建新的release-X.Y.Z分支并发布X.Y.Z-rc.1作为首个发布候选。每月 20 日将该发布分支发布到 crates.io并构建发布产物。这意味着 Wasmtime 的正式发布总是比main上的开发进度落后至少两周并且每月只发布一次。文档也明确说明大多数消费者应当使用发布分支而非main。完整的自动化步骤17文档以编号清单的形式详细列出了整个流程。其中需要人类维护者介入的步骤用加粗标注其余步骤全部由自动化完成。以下是对原文步骤的完整展开每月 5 日CI 任务自动执行由.github/workflows/release-process.yml配置下载当前main分支将main推送到release-X.0.0分支运行wasmtime-publishcrate 的bump-major参数提交变更将变更推送到一个临时的ci/*分支向main打开一个 PR然后从切出发布分支的那个 commit 重新开始运行wasmtime-publish的bump-rc参数将版本推进到X.0.0-rc.1在 commit message 中加入tag-and-release 标记并向release-X.0.0打开第二个 PR该步骤也可以通过工作流的手动触发workflow_dispatch配合main分支和cut参数来执行。一名 Wasmtime 维护者合并这两个 PR这两个 PR 只是版本号提升因此可以立即合并。合并发布分支的那个 PR 会以与正式发布相同的打 tag 发布路径发布X.0.0-rc.1区别仅在于 GitHub Release 被标记为 pre-release。时间推移release-X.0.0分支持续维护所有变更先落在main上再按需 backport 到release-X.0.0。如果累积的变更足够多、值得再次测试可以手动触发选择发布分支 release-rc参数发布下一个-rc.N合并对应 PR 后新候选发布前一个候选被 yank撤回。每月 20 日另一个 CI 任务执行Reset 到release-X.0.0运行wasmtime-publish的bump-drop-rc参数去掉-rc.N后缀使版本定格在X.0.0在RELEASES.md中将X.0.0的发布日期更新为今天在 commit message 中加入特殊标记表明应该创建 tag针对release-X.0.0打开一个 PR该步骤同样可以手动触发main分支 release-latest参数。一名维护者合并该 PR合并时由于 commit message 中的标记会触发后续步骤。维护者应再次确认[没有未解决的 RUSTSEC 安全问题]但其他发布相关问题此时应已全部解决。主 CI 工作流.github/workflows/main.yml的收尾特殊逻辑对release-*分支的推送会扫描被推送变更的 git log查找release-process.yml添加的特殊标记。如果找到标记且 CI 全部通过就创建并推送 tag。tag 创建后.github/workflows/publish-*工作流运行其中一个将所有 crate 原样发布到 crates.io另一个下载main.yml工作流的所有构建产物并将它们作为官方 release 上传。文档总结道如果一切顺利维护者几乎不需要阅读太多说明——只需要为自动生成的 PR 按下大绿按钮Big Green Button剩下的都会自动完成。源码视角release-process.yml工作流的关键实现在仓库的 .github/workflows/release-process.yml 中上述步骤以真实代码的形式落地其设计要点包括定时调度on.schedule配置了0 0 5 * *和0 0 20 * *两个 cron 表达式分别对应每月 5 日和 20 日的零点。手动触发workflow_dispatch暴露action输入可选值为cut、release-latest、release-rc、release-patch默认cut。分支切分逻辑通过cur_dev$(./ci/print-current-version.sh)获取当前-dev版本cur${cur_dev%-dev}去掉后缀得到即将发布的版本branchrelease-${cur_dev%-dev}构造分支名随后git push origin HEAD:$branch直接推送创建发布分支——这是文档中所说的脚本直接执行的写操作其他步骤则尽量通过 PR 交由人类审查。版本提升与发布说明整理切出分支后执行cargo run -p wasmtime-publish bump-major提升main上的版本随后用sed -i 0,/-----------/d RELEASES.md删除当前版本的发布说明将历史版本归档条目追加到ARCHIVE_START标记之后并用sed s/VERSION/$num/ ci/RELEASES-template.md RELEASES.md以模板重建新的发布说明文件。cargo vet 同步每次版本提升后都会运行cargo vet为新 crate 版本更新供应链审查条目。PR 自动创建工作流通过gh pr create向main版本提升 PR和release-X.Y.Z发布候选 PR分别发起 PR并在 PR 正文中说明用途。关键提交标记发布候选和正式发布的 commit message 都包含一行[automatically-tag-and-release-this-commit]这是后续触发打 tag 的暗号。正式发布准备release-latest分支执行bump-drop-rc去掉候选后缀并用sed -i s/^Unreleased/Released $(date %Y-%m-%d)/ RELEASES.md把Unreleased替换为实际发布日期。tag 的触发与创建机制文档第 6 步提到的特殊逻辑位于 .github/workflows/main.yml 的push-tagjob 中约第 1558 行起。该 job 只在release-*分支的 push 事件且全部 CI 成功后运行它会执行git log ${{ github.event.before }}...${{ github.event.after }} | tee main.log version$(grep ^version Cargo.toml | head -n 1 | sed s/.*\(.*\)/\1/) if grep -q automatically-tag-and-release-this-commit main.log; then echo push_tagyes fi即扫描 push 前后的 commit 历史若发现标记字符串则通过 GitHub API 创建refs/tags/vX.Y.Z。注释还解释了这样设计的原因通过 API 创建 tag 可以确保 tag 本身再次触发 CI从而驱动完整的发布流程同时push-tag依赖ci-statusjob保证 tag 只在构建产物上传完成之后创建因为后续的publish-artifacts.yml需要下载这些产物。发布产物与 crates.io 发布tag 创建后有两个publish-*工作流接力.github/workflows/publish-to-cratesio.yml 监听v*tag 的 push依次运行cargo run -p wasmtime-publish publish和cargo run -p wasmtime-publish yank-old-rcs并使用rust-lang/crates-io-auth-action完成 crates.io 认证随后还会构建并发布wasi-preview1-component-adapter-providercrate。.github/workflows/publish-artifacts.yml 下载main.yml工作流产生的构建产物通过./ci/merge-artifacts.sh合并生成 GitHub Releasemain分支的产物作为devpre-release 上传发布分支的产物则作为正式 release分支名含-时标记为 pre-release并取RELEASES.md中分隔线之前的内容作为 release notes。wasmtime-publish工具版本提升与发布的执行核心文档中反复提到的wasmtime-publishcrate 位于 crates/misc/publish/src/main.rs。它的文件头注释直接引用了本文所讲的文档并列出全部命令参数命令作用cargo run -p wasmtime-publish bump-major将所有 crate 版本提升到下一个-devcargo run -p wasmtime-publish bump-patch提升 patch 版本号cargo run -p wasmtime-publish bump-rc推进到下一个 release candidatecargo run -p wasmtime-publish bump-drop-rc去掉 pre-release 后缀cargo run -p wasmtime-publish verify验证 crate 可以发布到 crates.iocargo run -p wasmtime-publish publish实际发布 crate 到 crates.iocargo run -p wasmtime-publish yank-old-rcsyank 被取代的 release candidatecargo run -p wasmtime-publish latest-release打印最近一个 release 分支的版本号从源码结构看该工具在启动时会扫描crates、cranelift、pulley、winch四个目录下的所有Cargo.tomlfind_crates递归遍历读取每个 crate 的版本和publish标志默认true再按照CRATES_TO_PUBLISH定义的拓扑顺序排序后执行相应操作。CRATES_TO_PUBLISH拓扑排序的发布清单源码中CRATES_TO_PUBLISH数组按依赖关系拓扑排序覆盖了 Wasmtime 工作区中所有需要发布的一方才 crate从wasmtime-internal-core、cranelift-bitset开始依次是 pulleypulley-macros、pulley-interpreter、cranelift 全家cranelift-srcgen、cranelift-codegen、cranelift-frontend等、wiggle、wasmtime 本体及所有wasmtime-wasi-*系列、wasmtime-cli等约 65 个 crate。工具源码中的断言强制约束任何设置了publish true的 crate 必须出现在该列表中否则构建即报错——这保证了发布范围是显式、可审查的。PUBLIC_CRATES补丁发布的红线清单PUBLIC_CRATES数组列出了补丁发布中不允许发生 semver API 破坏的 crate包括wasmtime、wasmtime-wasi、wasmtime-wasi-http、wasmtime-cli、wasmtime-wizer以及所有 cranelift crate含wasmtime-types。与之相对的规则是不在该列表中的 crate 必须使用a.b.c的精确版本依赖从而允许在补丁版本中对其内部 API 进行破坏性修改——因为它们只是组织内部细节外部不应依赖。这一约束在bump_version函数中有具体实现遍历每个 manifest 的所有依赖表dependencies、dev-dependencies、build-dependencies、[workspace.dependencies]以及平台相关的[target.cfg(..).dependencies]对第一方才 crate 的依赖若依赖的是PUBLIC_CRATES中的 crate则必须使用 caret^宽松版本约束若依赖的是内部 crate则必须使用精确锁定。发布重试与 C API 版本同步源码还体现了发布大型多 crate 工作区时的工程细节publish命令会在一个最多 10 次的循环中反复尝试发布每次剔除已成功的 crate失败的 crate 等待 40 秒后重试以应对 crates.io 的限流和索引传播延迟全部成功后工具会提示手动推送vX.Y.Ztag。此外bump-*系列命令都会调用update_capi_version()同步更新 crates/c-api/include/wasmtime.h 中的版本宏——WASMTIME_VERSION字符串携带完整版本含 pre-release 后缀而数字宏只包含major.minor.patch三元组。补丁版本发布按需进行、人工介入更多Wasmtime 目前没有补丁版本的固定节奏或严格标准属于按需发布。但文档明确列出了硬性要求所有变更必须先落在main上如适用再 backport 到较旧的分支发布分支应已通过上述主版本流程存在。补丁发布必须应用到所有需要该补丁的受支持版本受支持版本清单见 docs/stability-release.md#current-versions。Wasmtime 不会在某个版本尚未同步打补丁时单独发布以保证各版本发布的一致性。补丁发布不得包含公共 crate 的 API 破坏性变更需要关注的是crates/misc/publish/src/main.rs中的PUBLIC_CRATES列表。默认不允许 Wasm 层面的 ABI 破坏性变更。例如用户应当能够加载补丁发布之前生成的*.cwasm产物。如果确实需要 ABI 破坏性变更必须更新 crates/wasmtime/src/engine/serialization.rs 中的WasmtimeVersion匹配策略修改版本字符串以确保旧产物无法被加载。关于第 4 点可以从源码中找到佐证crates/wasmtime/src/engine/serialization.rs 中ModuleVersionStrategy::WasmtimeVersion第 835 行附近正是将当前 Wasmtime 版本号编码进序列化模块产物的默认策略——Wasmtime 的序列化格式中携带版本信息加载*.cwasm时据此判断兼容性。以 2.0.1 为例的补丁发布步骤文档以2.0.1为例给出了补丁发布的操作清单人工介入步骤用加粗标注必要变更从mainbackport 到release-2.0.0分支受支持分支的 CI 在发布后仍每周运行以确保分支最多坏一周但仍需注意main上 CI 绿不代表 release 分支也绿。合并 backport 时维护者需要双重确认crates/misc/publish/src/main.rs中的PUBLIC_CRATES没有发生最严格意义上的semver API 破坏所有安全修复都必须以不破坏 API 的方式完成。别忘了在RELEASES.md中为 backport 的变更写补丁说明patch notes。手动触发补丁发布流程在 CI 的 release-process 工作流中选择release-2.0.0分支和release-patch参数。wasmtime-publish会以bump-patch参数运行变更提交时携带需要发布的特殊标记并从临时ci/*分支向release-2.0.0创建 PR——合并该 PR 即触发发布流程。审查生成的 PR 并合并这一步会接续主版本流程中的第 6 步——commit message 中由 CI 生成的特殊标记触发 tag 推送进而触发后续发布流程。合并前请确保此时已将RELEASES.md中的Released on日期直接 push 到与 PR 关联的分支上。上述步骤在工作流源码中对应release-patch分支.github/workflows/release-process.yml 第 230 行起执行bump-patch、运行cargo vet、用sed把Unreleased替换为发布日期最后以包含[automatically-tag-and-release-this-commit]标记的 commit 创建 PR。补丁发布相关的策略背景值得补充的是docs/stability-release.md 进一步界定了补丁发布的适用范围补丁版本只用于受支持版本中默认开启行为的安全问题与关键正确性问题修复并保证 API 与行为向后兼容、升级简单。例如当前版本为39.0.0时安全问题会同时发布39.0.x、38.0.x、36.0.x当前 LTS和24.0.x上一 LTS四个补丁版本。此外Cranelift 发现的任何 miscompilation 都会促成补丁发布且由于当前发布流程的耦合Cranelift 的补丁发布会连带触发 Wasmtime 的补丁发布。安全补丁发布对于安全相关的发布本文所依托的文档明确指向了专门的漏洞响应手册docs/security-vulnerability-runbook.md。安全修复遵循与普通 backport 相同的流程但区别在于发布日前会在私有环境中协调。维护者在执行正式发布前的最后一步时应当检查没有未解决的安全问题再合并触发发布的 PR。发布说明Release Notes管理Wasmtime 的发布说明写在仓库根目录的 RELEASES.md 中文档说明了其管理方式理论上main上的所有变更都应附带对RELEASES.md的相应更新但实践中几乎从未做到。当main分支版本号提升时RELEASES.md会被清空替换为 ci/RELEASES-template.md并在底部的版本列表中加入即将发布版本的条目。现实情况是release-X.Y.Z分支创建后发布说明直接在发布分支上更新和编辑。从模板文件 ci/RELEASES-template.md 可以看到其内容是一个以## VERSION开头的骨架包含Unreleased.占位、### Added与### Changed小节以及一条分隔线工作流通过sed s/VERSION/$num/将VERSION替换为真实版本号再追加历史归档内容。由于上述机制RELEASES.md只包含当前所在分支的发布说明历史版本说明通过文件底部的链接指向旧版RELEASES.md归档。需要注意的是main分支的版本提升会触发RELEASES.md的重置删除当前版本内容、插入归档条目这正是 .github/workflows/release-process.yml 中sed -i 0,/-----------/d RELEASES.md与ARCHIVE_START追加逻辑的职责。保持旧发布分支的 CI 可用随着时间推移CI 配置会逐渐过时。Wasmtime 仓库通过 GitHub Actions 的 cron job每周在所有受支持的发布分支上运行一次发布 CI以尽早发现此类问题。如果某个发布分支的 CI 失败会自动开 issue维护者需要尽快解决。文档还给出了一条务实的原则尽量不通过升级软件来修复旧分支的 CI对于此前未固定的依赖尽量固定到较旧版本。当然有时升级不可避免那就必须升级。维护者操作速查综合文档全文以下操作节点需要维护者人工介入值得作为速查清单保存时机操作触发方式每月 5 日或手动cut合并两个自动生成的 PRmain版本提升 PR release-X.Y.Z的-rc.1发布 PR自动生成人工合并需要更多验证时以release-rc手动触发合并生成的候选发布 PR手动触发每月 20 日或手动release-latest确认无未解决安全问题、RELEASES.md内容正确后合并正式发布 PR自动生成人工合并需要补丁发布时先 backport 到发布分支并写 patch notes再以release-patch触发合并生成的 PR手动触发每周检查发布分支的每周 CI若失败则尽快修复cron 自动运行结语Wasmtime 的发布流程是策略文档 自动化工作流 专用工具三者协同的典型范例docs/contributing-release-process.md定义流程与人工介入点.github/workflows/release-process.yml 负责每月两次的定时切分支、版本提升与 PR 创建crates/misc/publish/src/main.rs 中的wasmtime-publish工具承担版本改写、依赖约束校验与 crates.io 发布而 .github/workflows/main.yml 的push-tagjob 与两个publish-*工作流则在标记的驱动下完成打 tag、发布 crate 与上传产物。理解这条链路后无论是作为维护者执行一次发布还是作为使用者追踪某个版本的来历都能快速定位到对应的代码与文档位置。对于发布节奏、受支持版本与候选版保障等策略层面的问题可进一步阅读 docs/stability-release.md。【免费下载链接】wasmtimeA lightweight WebAssembly runtime that is fast, secure, and standards-compliant项目地址: https://gitcode.com/gh_mirrors/wa/wasmtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考