wgpu 发布流程实战指南从版本号到 crates.io 的大版本与小版本发布全流程【免费下载链接】wgpuA cross-platform, safe, pure-Rust graphics API.项目地址: https://gitcode.com/GitHub_Trending/wg/wgpu本篇指南基于 docs/release-checklist.md 编写完整梳理 wgpu 项目一个跨平台、安全、纯 Rust 的图形 API的官方发布流程包括每 12 周一次的大版本Major破坏性发布、按需进行的补丁Patch发布以及发布前的依赖协调、CHANGELOG 整理、版本号同步、crates.io 发布、Git 标签创建、分支维护与社区公告等全部环节。读完本文你将掌握一套可直接照搬的 wgpu 发布操作手册并理解其背后的仓库结构如工作区版本继承、publish false的 crate、CHANGELOG 分类约定是如何支撑这套流程的。发布模型总览固定节奏 按需补丁wgpu 采用固定大版本 灵活补丁的双轨发布模型这一点在 docs/release-checklist.md 的Structure一节有明确约定大版本Major每12 周发布一次带有破坏性变更的版本且无论当时有多少进行中的功能in-flight projects尚未完成都按时发布。这一硬性节奏保证了下游生态如 Bevy、Firefox 等有一个可预期的升级窗口。补丁版本Patch在两个大版本之间的数周内按需发布。一旦新的 major 版本发布除非遇到关键 Bug 或编译问题否则停止为上一个 major 版本继续打补丁。谁可以执行发布流程对人员没有严格的排他性限制gfx-rs/wgpu团队的任意成员都可以按照 checklist 执行发布。这要求整套流程高度文档化、步骤可复现——这正是本清单存在的意义。版本号从哪里来发布流程的起点是根目录 Cargo.toml 中的[workspace.package]版本号。当前仓库的版本配置如下[workspace.package] edition 2021 rust-version 1.93 license MIT OR Apache-2.0 version 30.0.0这是整个工作区workspace的单一版本事实来源wgpu、wgpu-core、wgpu-hal、wgpu-types、naga、naga-types、wgpu-core-remote、wgpu-sync、wgpu-naga-bridge等 crate 都通过version.workspace true继承这个版本号。因此 checklist 中的第一条更新根Cargo.toml的版本号就会更新所有 crate 的版本是有据可依的——例如 wgpu/Cargo.toml 中的version.workspace true与 naga/Cargo.toml 中的version.workspace true。值得注意的是wgpu与naga各自在[package]中覆盖了rust-version两者均为1.87低于工作区的1.93这是为了给下游用户更宽松的 MSRV 升级空间发布时无需也不应改动这两处。大版本Major发布发布前约 1 周的准备大版本发布不是当天改个号就发流程要求提前约一周开始准备核心工作有两项依赖 crate 协调与 CHANGELOG 整理。1. 协调上游依赖 crate 的发布发布前需要判断依赖树中的关键 crate 是否也要同步发布新版本典型代表是glowGLES 后端的 OpenGL 绑定库维护者为 grovesrspirvSPIR-V 汇编/反汇编库由gfx-rs/wgpu团队维护以及其他被 wgpu 依赖、且本次发布需要新版本的 crate。如果需要必须提前与这些 crate 的维护者协调发布时间确保 crates.io 上的依赖版本与 wgpu 新版本兼容。这一协调并非走过场wgpu 的下游尤其是 Firefox对依赖版本极其敏感——如 docs/managing-cargo-dependencies.md 所述Firefox 需要通过cargo-vet审计每一个引入的依赖且会尽量避免 SemVer 不兼容升级带来的依赖重复。因此依赖版本的大幅变动会直接影响 wgpu 被下游接纳的难度。2. 通读并整理 CHANGELOG发布前需要过一遍 CHANGELOG.md做四件事重新归类Re-categorize放错分类的条目改写重大变更让用户一眼看懂升级到新版本我需要改什么补充遗漏的重大变更凡是用户升级时需要知晓的破坏性改动都不能缺通篇 copy-edit保证文字清晰。当前 CHANGELOG.md 的Unreleased段即展示了这套分类约定顶层分类有Major changes、Added/New Features、Changes、Bug Fixes、Performance、Documentation、Dependency Updates、deno_webgpu、Examples、Testing/Internal底层分类则有General、naga、Validation、DX12、Vulkan、Metal、GLES / OpenGL、WebGPU、Emscripten、Hal。条目通常以- 描述. By 作者 in [#PR号]的格式书写重大变更还会附上diff形式的新旧代码对照例如Unreleased中TEXTURE_COMPONENT_SWIZZLE功能对TextureViewDescriptor新增swizzle字段的迁移示例。大版本发布发布当天逐步操作以下是 checklist 中发布当天的完整操作序列按执行顺序展开。1. 提升版本号将根目录 Cargo.toml 的[workspace.package] version改为新版本号如30.0.0→31.0.0。由于所有 crate 均继承工作区版本这一处修改即完成了全工作区的版本提升。2. 同步 wgpu 依赖版本号Bump除工作区自身外还需要把对外暴露的wgpu依赖版本号同步到新版本涉及位置根 Cargo.toml 的[workspace.dependencies]如wgpu { version 30.0.0, path ./wgpu, ... }examples/standalone/*下的每个独立示例 crateexamples/bug-repro/*下的每个 Bug 复现 crate。这些示例之所以需要单独 bump是因为它们不通过path依赖本地代码而是声明对 crates.io 发布版本的依赖。例如 examples/standalone/01_hello_compute/Cargo.toml 中写着[dependencies] wgpu 30.0.0这类 crate 会被克隆出去作为用户项目的起点examples/README.md 明确说明它们可以被克隆出仓库作为自己项目的起点因此其依赖版本必须始终指向已发布的 crates.io 版本而不能指向工作区内部的 path 版本。3. 全文搜索旧版本号更新文档链接用 grep 检索上一个版本号确保仓库内的文档、示例说明中的版本链接均已更新。checklist 给出的示例如果上一个版本是v24.0.0则搜索v24与24.0两处。grep -rn v24\|24\.0 --include*.md --include*.rs --include*.toml .像 examples/README.md 顶部[!NOTE]中指向latest release branch v30的链接就是这类需要随版本更新的典型位置。4. 更新依赖 crate如准备阶段协调的那样将glow、rspirv如需要更新到最新版本。以当前仓库为例根 Cargo.toml 中glow 0.18、rspirv 0.13v30.0.1 的 CHANGELOG 中也出现过Updateglowto 0.18 for wasm64 support这样的依赖更新条目。5. 为 CHANGELOG 添加新版本标题在 CHANGELOG.md 顶部Unreleased之上新增一个以版本号和日期命名的标题例如## v30.0.0 (2026-07-01)。发布完成后原Unreleased的全部内容就归属于该版本。6. 创建 PR 并等待 CI将所有版本号变更与 CHANGELOG 更新汇总为一个 PR。在等待 PR 合并期间先做一次发布 dry-runcargo publish --dry-run --workspace --all-features --exclude deno_webgpu这条命令的细节值得注意--dry-run不真正上传到 crates.io只做打包、校验与本地验证--workspace遍历整个工作区--all-features以全部 feature 组合验证打包避免某些 feature 下编译不过--exclude deno_webgpu排除deno_webgpu——它虽然在工作区 members 中但publish false见 deno_webgpu/Cargo.toml是 Deno 运行时内置的 WebGPU 实现不通过 wgpu 的发布流程上 crates.io。7. 合并 PR 并发布待 PR 的 CI 通过且 dry-run 成功之后(force) merge该 PR切回trunk分支git checkout trunk git pull确保在最新代码上发布执行真正的发布命令可直接整段粘贴到终端cargo publish --workspace --all-features --exclude deno_webgpu8. 处理新 crate 的 owner如果本次发布产生了新发布的 crate此前从未发布过需要确保github:gfx-rs:wgpu被添加为该 crate 的 owner以保证后续版本仍能由团队发布cargo owner --add github:gfx-rs:wgpu crate-name9. 打标签Tags创建一个签名标签vX.Y.Z并推送到仓库例如git tag -s v30.0.0 -m wgpu v30.0.0 git push origin v30.0.0对每一个参与发布的 crate即所有可publish且不属于deno*的 crate再创建形如{crate_name}-vX.Y.Z的标签例如wgpu-v30.0.0、wgpu-core-v30.0.0、wgpu-hal-v30.0.0、naga-v30.0.0等。这样下游可以精确定位某个 crate 的某个发布版本。10. 创建 GitHub Release在wgpu仓库基于刚打的vX.Y.Z标签创建一个新 release正文内容使用本版本的 CHANGELOG。注意 GitHub Release 是社区与下游用户感知发布的主要入口因此文案应直接复用已整理好的 changelog 段落。11. 创建版本分支vX并清理示例提示创建一个以新版本命名的新分支vX例如v30并推送在该分支上移除 examples/README.md 顶部的[!NOTE]提示块。该 NOTE 的内容是这些示例面向 wgpu 开发版本如需查看最新 crates.io 发布版的示例请前往 latest release branch——版本分支上的示例对应已发布版本不再需要这条提示。12. 里程碑管理完成close本次发布对应的 GitHub milestone创建下一个里程碑时间设在 12 周之后与下一个 major 发布对齐。13. 更新发布清单本身把本次发布中发现的任何流程改进、新增步骤、踩坑经验回写到 docs/release-checklist.md。这份文档是活文档每次发布后都应沉淀增量经验。14. 社区公告将 GitHub Release 链接发布到以下社区渠道checklist 原文要求的发布位r/rust子版块发布帖子并添加一个AMAAsk Me Anything评论r/rust_gamedev子版块交叉转发crosspost同样附 AMA 评论wgpu Matrix频道#wgpu:matrix.orgRust Gamedev Discord的#crates与#wgpu频道Bevy Discord的#rendering-dev频道Graphics Programming Discord的#webgpu频道Rust Community Discord的#games-and-graphics频道。r/rust 的帖子短链接应一并包含在上述各渠道的转发中方便社区统一跳转讨论。补丁Patch发布流程backport 的艺术大版本之间的补丁发布流程与 major 流程部分重叠但最大的差异在于如何把 trunk 上的修复搬回版本分支。1. 枚举待 backport 的 PR补丁发布的第一步是枚举所有尚未 backport 的 PR。这些 PR 在 GitHub 上带有PR: needs back-porting标签可以通过标签筛选拉取完整列表。凡是合并进 trunk、但又需要进入最新发布分支的修复都会被打上该标签。2. 在自己的分支上 cherry-pick不要直接在发布分支上操作。基于最新的发布分支release branch新建自己的分支然后逐一 cherry-pick 需要 backport 的 PR。关键细节修改这些提交时使用--append选项以保留原作者original authorshipgit checkout v30 git checkout -b backport-v30-fixes git cherry-pick --append commit-sha-1 commit-sha-2 ...--append会在保留原提交作者信息的同时追加说明避免 commit 的作者被改写为执行 backport 的人这对开源社区的贡献归属至关重要。3. 清理标签对每个已 backport 的 PR移除needs-backport标签避免下一次枚举时重复处理。4. 更新 CHANGELOG 并创建 PR修正 CHANGELOG 中本次补丁相关的条目只保留真正进入补丁版本的改动并在顶部添加新标题例如## v30.0.1 (2026-08-21)。然后将版本号变更与 CHANGELOG 更新整合为一个 PR目标分支是发布分支而非 trunk。5. dry-run 与合并与 major 流程相同等待 PR 期间先跑 dry-runcargo publish --dry-run --workspace --all-features --exclude deno_webgpuCI 通过且 dry-run 成功后(force) merge然后checkout 版本分支并执行正式发布git checkout v30 git pull cargo publish --workspace --all-features --exclude deno_webgpu6. 创建 Release 与标签在发布分支上基于新标签vX.Y.Z如v30.0.1创建 GitHub Release正文包含本补丁版本的 CHANGELOG同时对每个发布的 crate 创建{crate_name}-vX.Y.Z标签。7. 将 changelog 与版本号 backport 回 trunk补丁版本发布后还需要把发布分支上的 CHANGELOG 与版本号改动同步回trunk并特别注意已发布的补丁版本中的 changelog 条目绝不能残留在 trunk 的Unreleased段——否则会出现在下个大版本的 changelog 中造成条目重复。当前仓库正是这套流程的实例CHANGELOG.md 中v30.0.1 (2026-08-21)的 WebGPU 条目明确标注backported in #10105而v30.0.0 (2026-07-01)紧随其后二者之间不存在条目交叉——这正是 backport 后清理Unreleased的效果。8. 更新发布清单与 major 流程一致将补丁流程中发现的改进回写到 docs/release-checklist.md。仓库视角这套流程背后的工程支撑理解发布流程的最佳方式是同时看清仓库中与发布相关的工程细节工作区版本继承根 Cargo.toml 定义了约 30 个 workspace memberswgpu、wgpu-core、wgpu-hal、wgpu-types、naga、naga-types、wgpu-core-remote、wgpu-sync、wgpu-naga-bridge、benches、examples/features、examples/standalone/*、examples/bug-repro/*、player、tests、xtask等并声明default-members保证日常构建范围。绝大多数 crate 通过version.workspace true继承[workspace.package] version这是改一个版本号全仓生效的机制基础。特殊成员的处理deno_webgpu工作区成员但publish false见 deno_webgpu/Cargo.toml因此发布命令始终以--exclude deno_webgpu排除它examples/standalone/*、examples/bug-repro/*独立 crate 且大多publish false如 examples/standalone/01_hello_compute/Cargo.toml但它们声明了对 crates.io 上wgpu版本号的依赖所以每次 major 发布都必须同步 bump 其wgpu依赖naga/hlsl-snapshots根 Cargo.toml 的注释特别说明它不能指定版本号——一旦指定发布naga时 crates.io 会去查找该版本的包导致发布失败因此它只能作为纯 path 依赖存在。这提醒我们发布前检查所有 crate 的依赖声明方式version path、纯 path、纯 version同样重要。CI 与发布的关系仓库的 .github/workflows/publish.yml 名为 Publish但其实际职责是安装 wasm target 与wasm-bindgen-cli、构建全部 WebGPU 示例cargo xtask run-wasm --no-serve并在 trunk 分支上将生成的示例页面部署到wgpu-rs.github.io的examples/目录。也就是说crates.io 的发布是由清单中的人工cargo publish命令完成的CI 发布流程承担的是示例站点的持续部署。二者共同构成了代码发布crates.io与示例站点发布GitHub Pages的完整闭环。CHANGELOG 的机器可读结构CHANGELOG.md 头部用 HTML 注释给出了条目书写的完整规范分类清单与示例格式每个条目带 PR 链接与作者。规范化的分类结构让重新归类、按版本切片生成 Release 正文这些发布动作都可以半自动化执行这也是发布 checklist 敢要求通读整理 changelog的前提。发布全流程速查表以下把 major 与 patch 两条流程浓缩为速查清单便于发布执行者对照操作阶段Major 发布Patch 发布节奏每 12 周一次破坏性变更准时发布按需新 major 后仅修关键 Bug/编译问题准备提前 1 周协调glow/rspirv等依赖 crate整理 CHANGELOG归类/改写/补漏/润色枚举PR: needs back-porting标签 PR版本号根 Cargo.toml[workspace.package] version同步到补丁版本号依赖 bump根 Cargo.toml、examples/standalone/*、examples/bug-repro/*同左按需版本残留检查grep 上一版本号如v24、24.0—变更落地创建 PR → dry-run → CI 通过后 (force) merge → checkout trunk基于发布分支建自己的分支 cherry-pick--append→ 移除 label → PR 到发布分支发布命令cargo publish --workspace --all-features --exclude deno_webgpu同左在发布分支执行新 crate添加github:gfx-rs:wgpu为 owner—标签签名 tagvX.Y.Z 各 crate{crate_name}-vX.Y.Z同左Release基于vX.Y.Z创建正文用本版 CHANGELOG同左分支创建vX分支移除 examples/README.md 顶部[!NOTE]将 changelog/版本号 backport 回 trunk清理Unreleased残留条目里程碑完成旧里程碑创建 12 周后的新里程碑—收尾更新 checklist向 r/rust含 AMA等 7 渠道发布公告更新 checklist结语wgpu 的发布流程是一套固定节奏 严格 checklist 明确的仓库工程支撑的成熟实践根 Cargo.toml 的版本继承机制让版本号同步只需一处修改CHANGELOG 的强分类规范让重大变更对用户可读、可迁移--exclude deno_webgpu与独立示例 crate 的依赖声明则界定了发布边界而签名标签、per-crate 标签与vX分支共同构成了可回溯、可维护的版本历史。对于任何想要照搬这套发布体系的 Rust 工作区项目而言docs/release-checklist.md 本身就是一份高质量的操作蓝本。【免费下载链接】wgpuA cross-platform, safe, pure-Rust graphics API.项目地址: https://gitcode.com/GitHub_Trending/wg/wgpu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
wgpu 发布流程实战指南：从版本号到 crates.io 的大版本与小版本发布全流程
wgpu 发布流程实战指南从版本号到 crates.io 的大版本与小版本发布全流程【免费下载链接】wgpuA cross-platform, safe, pure-Rust graphics API.项目地址: https://gitcode.com/GitHub_Trending/wg/wgpu本篇指南基于 docs/release-checklist.md 编写完整梳理 wgpu 项目一个跨平台、安全、纯 Rust 的图形 API的官方发布流程包括每 12 周一次的大版本Major破坏性发布、按需进行的补丁Patch发布以及发布前的依赖协调、CHANGELOG 整理、版本号同步、crates.io 发布、Git 标签创建、分支维护与社区公告等全部环节。读完本文你将掌握一套可直接照搬的 wgpu 发布操作手册并理解其背后的仓库结构如工作区版本继承、publish false的 crate、CHANGELOG 分类约定是如何支撑这套流程的。发布模型总览固定节奏 按需补丁wgpu 采用固定大版本 灵活补丁的双轨发布模型这一点在 docs/release-checklist.md 的Structure一节有明确约定大版本Major每12 周发布一次带有破坏性变更的版本且无论当时有多少进行中的功能in-flight projects尚未完成都按时发布。这一硬性节奏保证了下游生态如 Bevy、Firefox 等有一个可预期的升级窗口。补丁版本Patch在两个大版本之间的数周内按需发布。一旦新的 major 版本发布除非遇到关键 Bug 或编译问题否则停止为上一个 major 版本继续打补丁。谁可以执行发布流程对人员没有严格的排他性限制gfx-rs/wgpu团队的任意成员都可以按照 checklist 执行发布。这要求整套流程高度文档化、步骤可复现——这正是本清单存在的意义。版本号从哪里来发布流程的起点是根目录 Cargo.toml 中的[workspace.package]版本号。当前仓库的版本配置如下[workspace.package] edition 2021 rust-version 1.93 license MIT OR Apache-2.0 version 30.0.0这是整个工作区workspace的单一版本事实来源wgpu、wgpu-core、wgpu-hal、wgpu-types、naga、naga-types、wgpu-core-remote、wgpu-sync、wgpu-naga-bridge等 crate 都通过version.workspace true继承这个版本号。因此 checklist 中的第一条更新根Cargo.toml的版本号就会更新所有 crate 的版本是有据可依的——例如 wgpu/Cargo.toml 中的version.workspace true与 naga/Cargo.toml 中的version.workspace true。值得注意的是wgpu与naga各自在[package]中覆盖了rust-version两者均为1.87低于工作区的1.93这是为了给下游用户更宽松的 MSRV 升级空间发布时无需也不应改动这两处。大版本Major发布发布前约 1 周的准备大版本发布不是当天改个号就发流程要求提前约一周开始准备核心工作有两项依赖 crate 协调与 CHANGELOG 整理。1. 协调上游依赖 crate 的发布发布前需要判断依赖树中的关键 crate 是否也要同步发布新版本典型代表是glowGLES 后端的 OpenGL 绑定库维护者为 grovesrspirvSPIR-V 汇编/反汇编库由gfx-rs/wgpu团队维护以及其他被 wgpu 依赖、且本次发布需要新版本的 crate。如果需要必须提前与这些 crate 的维护者协调发布时间确保 crates.io 上的依赖版本与 wgpu 新版本兼容。这一协调并非走过场wgpu 的下游尤其是 Firefox对依赖版本极其敏感——如 docs/managing-cargo-dependencies.md 所述Firefox 需要通过cargo-vet审计每一个引入的依赖且会尽量避免 SemVer 不兼容升级带来的依赖重复。因此依赖版本的大幅变动会直接影响 wgpu 被下游接纳的难度。2. 通读并整理 CHANGELOG发布前需要过一遍 CHANGELOG.md做四件事重新归类Re-categorize放错分类的条目改写重大变更让用户一眼看懂升级到新版本我需要改什么补充遗漏的重大变更凡是用户升级时需要知晓的破坏性改动都不能缺通篇 copy-edit保证文字清晰。当前 CHANGELOG.md 的Unreleased段即展示了这套分类约定顶层分类有Major changes、Added/New Features、Changes、Bug Fixes、Performance、Documentation、Dependency Updates、deno_webgpu、Examples、Testing/Internal底层分类则有General、naga、Validation、DX12、Vulkan、Metal、GLES / OpenGL、WebGPU、Emscripten、Hal。条目通常以- 描述. By 作者 in [#PR号]的格式书写重大变更还会附上diff形式的新旧代码对照例如Unreleased中TEXTURE_COMPONENT_SWIZZLE功能对TextureViewDescriptor新增swizzle字段的迁移示例。大版本发布发布当天逐步操作以下是 checklist 中发布当天的完整操作序列按执行顺序展开。1. 提升版本号将根目录 Cargo.toml 的[workspace.package] version改为新版本号如30.0.0→31.0.0。由于所有 crate 均继承工作区版本这一处修改即完成了全工作区的版本提升。2. 同步 wgpu 依赖版本号Bump除工作区自身外还需要把对外暴露的wgpu依赖版本号同步到新版本涉及位置根 Cargo.toml 的[workspace.dependencies]如wgpu { version 30.0.0, path ./wgpu, ... }examples/standalone/*下的每个独立示例 crateexamples/bug-repro/*下的每个 Bug 复现 crate。这些示例之所以需要单独 bump是因为它们不通过path依赖本地代码而是声明对 crates.io 发布版本的依赖。例如 examples/standalone/01_hello_compute/Cargo.toml 中写着[dependencies] wgpu 30.0.0这类 crate 会被克隆出去作为用户项目的起点examples/README.md 明确说明它们可以被克隆出仓库作为自己项目的起点因此其依赖版本必须始终指向已发布的 crates.io 版本而不能指向工作区内部的 path 版本。3. 全文搜索旧版本号更新文档链接用 grep 检索上一个版本号确保仓库内的文档、示例说明中的版本链接均已更新。checklist 给出的示例如果上一个版本是v24.0.0则搜索v24与24.0两处。grep -rn v24\|24\.0 --include*.md --include*.rs --include*.toml .像 examples/README.md 顶部[!NOTE]中指向latest release branch v30的链接就是这类需要随版本更新的典型位置。4. 更新依赖 crate如准备阶段协调的那样将glow、rspirv如需要更新到最新版本。以当前仓库为例根 Cargo.toml 中glow 0.18、rspirv 0.13v30.0.1 的 CHANGELOG 中也出现过Updateglowto 0.18 for wasm64 support这样的依赖更新条目。5. 为 CHANGELOG 添加新版本标题在 CHANGELOG.md 顶部Unreleased之上新增一个以版本号和日期命名的标题例如## v30.0.0 (2026-07-01)。发布完成后原Unreleased的全部内容就归属于该版本。6. 创建 PR 并等待 CI将所有版本号变更与 CHANGELOG 更新汇总为一个 PR。在等待 PR 合并期间先做一次发布 dry-runcargo publish --dry-run --workspace --all-features --exclude deno_webgpu这条命令的细节值得注意--dry-run不真正上传到 crates.io只做打包、校验与本地验证--workspace遍历整个工作区--all-features以全部 feature 组合验证打包避免某些 feature 下编译不过--exclude deno_webgpu排除deno_webgpu——它虽然在工作区 members 中但publish false见 deno_webgpu/Cargo.toml是 Deno 运行时内置的 WebGPU 实现不通过 wgpu 的发布流程上 crates.io。7. 合并 PR 并发布待 PR 的 CI 通过且 dry-run 成功之后(force) merge该 PR切回trunk分支git checkout trunk git pull确保在最新代码上发布执行真正的发布命令可直接整段粘贴到终端cargo publish --workspace --all-features --exclude deno_webgpu8. 处理新 crate 的 owner如果本次发布产生了新发布的 crate此前从未发布过需要确保github:gfx-rs:wgpu被添加为该 crate 的 owner以保证后续版本仍能由团队发布cargo owner --add github:gfx-rs:wgpu crate-name9. 打标签Tags创建一个签名标签vX.Y.Z并推送到仓库例如git tag -s v30.0.0 -m wgpu v30.0.0 git push origin v30.0.0对每一个参与发布的 crate即所有可publish且不属于deno*的 crate再创建形如{crate_name}-vX.Y.Z的标签例如wgpu-v30.0.0、wgpu-core-v30.0.0、wgpu-hal-v30.0.0、naga-v30.0.0等。这样下游可以精确定位某个 crate 的某个发布版本。10. 创建 GitHub Release在wgpu仓库基于刚打的vX.Y.Z标签创建一个新 release正文内容使用本版本的 CHANGELOG。注意 GitHub Release 是社区与下游用户感知发布的主要入口因此文案应直接复用已整理好的 changelog 段落。11. 创建版本分支vX并清理示例提示创建一个以新版本命名的新分支vX例如v30并推送在该分支上移除 examples/README.md 顶部的[!NOTE]提示块。该 NOTE 的内容是这些示例面向 wgpu 开发版本如需查看最新 crates.io 发布版的示例请前往 latest release branch——版本分支上的示例对应已发布版本不再需要这条提示。12. 里程碑管理完成close本次发布对应的 GitHub milestone创建下一个里程碑时间设在 12 周之后与下一个 major 发布对齐。13. 更新发布清单本身把本次发布中发现的任何流程改进、新增步骤、踩坑经验回写到 docs/release-checklist.md。这份文档是活文档每次发布后都应沉淀增量经验。14. 社区公告将 GitHub Release 链接发布到以下社区渠道checklist 原文要求的发布位r/rust子版块发布帖子并添加一个AMAAsk Me Anything评论r/rust_gamedev子版块交叉转发crosspost同样附 AMA 评论wgpu Matrix频道#wgpu:matrix.orgRust Gamedev Discord的#crates与#wgpu频道Bevy Discord的#rendering-dev频道Graphics Programming Discord的#webgpu频道Rust Community Discord的#games-and-graphics频道。r/rust 的帖子短链接应一并包含在上述各渠道的转发中方便社区统一跳转讨论。补丁Patch发布流程backport 的艺术大版本之间的补丁发布流程与 major 流程部分重叠但最大的差异在于如何把 trunk 上的修复搬回版本分支。1. 枚举待 backport 的 PR补丁发布的第一步是枚举所有尚未 backport 的 PR。这些 PR 在 GitHub 上带有PR: needs back-porting标签可以通过标签筛选拉取完整列表。凡是合并进 trunk、但又需要进入最新发布分支的修复都会被打上该标签。2. 在自己的分支上 cherry-pick不要直接在发布分支上操作。基于最新的发布分支release branch新建自己的分支然后逐一 cherry-pick 需要 backport 的 PR。关键细节修改这些提交时使用--append选项以保留原作者original authorshipgit checkout v30 git checkout -b backport-v30-fixes git cherry-pick --append commit-sha-1 commit-sha-2 ...--append会在保留原提交作者信息的同时追加说明避免 commit 的作者被改写为执行 backport 的人这对开源社区的贡献归属至关重要。3. 清理标签对每个已 backport 的 PR移除needs-backport标签避免下一次枚举时重复处理。4. 更新 CHANGELOG 并创建 PR修正 CHANGELOG 中本次补丁相关的条目只保留真正进入补丁版本的改动并在顶部添加新标题例如## v30.0.1 (2026-08-21)。然后将版本号变更与 CHANGELOG 更新整合为一个 PR目标分支是发布分支而非 trunk。5. dry-run 与合并与 major 流程相同等待 PR 期间先跑 dry-runcargo publish --dry-run --workspace --all-features --exclude deno_webgpuCI 通过且 dry-run 成功后(force) merge然后checkout 版本分支并执行正式发布git checkout v30 git pull cargo publish --workspace --all-features --exclude deno_webgpu6. 创建 Release 与标签在发布分支上基于新标签vX.Y.Z如v30.0.1创建 GitHub Release正文包含本补丁版本的 CHANGELOG同时对每个发布的 crate 创建{crate_name}-vX.Y.Z标签。7. 将 changelog 与版本号 backport 回 trunk补丁版本发布后还需要把发布分支上的 CHANGELOG 与版本号改动同步回trunk并特别注意已发布的补丁版本中的 changelog 条目绝不能残留在 trunk 的Unreleased段——否则会出现在下个大版本的 changelog 中造成条目重复。当前仓库正是这套流程的实例CHANGELOG.md 中v30.0.1 (2026-08-21)的 WebGPU 条目明确标注backported in #10105而v30.0.0 (2026-07-01)紧随其后二者之间不存在条目交叉——这正是 backport 后清理Unreleased的效果。8. 更新发布清单与 major 流程一致将补丁流程中发现的改进回写到 docs/release-checklist.md。仓库视角这套流程背后的工程支撑理解发布流程的最佳方式是同时看清仓库中与发布相关的工程细节工作区版本继承根 Cargo.toml 定义了约 30 个 workspace memberswgpu、wgpu-core、wgpu-hal、wgpu-types、naga、naga-types、wgpu-core-remote、wgpu-sync、wgpu-naga-bridge、benches、examples/features、examples/standalone/*、examples/bug-repro/*、player、tests、xtask等并声明default-members保证日常构建范围。绝大多数 crate 通过version.workspace true继承[workspace.package] version这是改一个版本号全仓生效的机制基础。特殊成员的处理deno_webgpu工作区成员但publish false见 deno_webgpu/Cargo.toml因此发布命令始终以--exclude deno_webgpu排除它examples/standalone/*、examples/bug-repro/*独立 crate 且大多publish false如 examples/standalone/01_hello_compute/Cargo.toml但它们声明了对 crates.io 上wgpu版本号的依赖所以每次 major 发布都必须同步 bump 其wgpu依赖naga/hlsl-snapshots根 Cargo.toml 的注释特别说明它不能指定版本号——一旦指定发布naga时 crates.io 会去查找该版本的包导致发布失败因此它只能作为纯 path 依赖存在。这提醒我们发布前检查所有 crate 的依赖声明方式version path、纯 path、纯 version同样重要。CI 与发布的关系仓库的 .github/workflows/publish.yml 名为 Publish但其实际职责是安装 wasm target 与wasm-bindgen-cli、构建全部 WebGPU 示例cargo xtask run-wasm --no-serve并在 trunk 分支上将生成的示例页面部署到wgpu-rs.github.io的examples/目录。也就是说crates.io 的发布是由清单中的人工cargo publish命令完成的CI 发布流程承担的是示例站点的持续部署。二者共同构成了代码发布crates.io与示例站点发布GitHub Pages的完整闭环。CHANGELOG 的机器可读结构CHANGELOG.md 头部用 HTML 注释给出了条目书写的完整规范分类清单与示例格式每个条目带 PR 链接与作者。规范化的分类结构让重新归类、按版本切片生成 Release 正文这些发布动作都可以半自动化执行这也是发布 checklist 敢要求通读整理 changelog的前提。发布全流程速查表以下把 major 与 patch 两条流程浓缩为速查清单便于发布执行者对照操作阶段Major 发布Patch 发布节奏每 12 周一次破坏性变更准时发布按需新 major 后仅修关键 Bug/编译问题准备提前 1 周协调glow/rspirv等依赖 crate整理 CHANGELOG归类/改写/补漏/润色枚举PR: needs back-porting标签 PR版本号根 Cargo.toml[workspace.package] version同步到补丁版本号依赖 bump根 Cargo.toml、examples/standalone/*、examples/bug-repro/*同左按需版本残留检查grep 上一版本号如v24、24.0—变更落地创建 PR → dry-run → CI 通过后 (force) merge → checkout trunk基于发布分支建自己的分支 cherry-pick--append→ 移除 label → PR 到发布分支发布命令cargo publish --workspace --all-features --exclude deno_webgpu同左在发布分支执行新 crate添加github:gfx-rs:wgpu为 owner—标签签名 tagvX.Y.Z 各 crate{crate_name}-vX.Y.Z同左Release基于vX.Y.Z创建正文用本版 CHANGELOG同左分支创建vX分支移除 examples/README.md 顶部[!NOTE]将 changelog/版本号 backport 回 trunk清理Unreleased残留条目里程碑完成旧里程碑创建 12 周后的新里程碑—收尾更新 checklist向 r/rust含 AMA等 7 渠道发布公告更新 checklist结语wgpu 的发布流程是一套固定节奏 严格 checklist 明确的仓库工程支撑的成熟实践根 Cargo.toml 的版本继承机制让版本号同步只需一处修改CHANGELOG 的强分类规范让重大变更对用户可读、可迁移--exclude deno_webgpu与独立示例 crate 的依赖声明则界定了发布边界而签名标签、per-crate 标签与vX分支共同构成了可回溯、可维护的版本历史。对于任何想要照搬这套发布体系的 Rust 工作区项目而言docs/release-checklist.md 本身就是一份高质量的操作蓝本。【免费下载链接】wgpuA cross-platform, safe, pure-Rust graphics API.项目地址: https://gitcode.com/GitHub_Trending/wg/wgpu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考