gfx-rs/wgpu 项目发布流程详解-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00285/article/details/148378210

gfx-rs/wgpu 项目发布流程详解

wgpu Cross-platform, safe, pure-rust graphics api. 项目地址: https://gitcode.com/gh_mirrors/wg/wgpu

前言

wgpu 是一个基于 WebGPU API 规范的 Rust 图形库实现，它提供了跨平台的图形和计算能力。作为项目维护的重要组成部分，发布流程需要严格遵循规范以确保稳定性和兼容性。本文将详细介绍 wgpu 项目的发布机制和具体操作步骤。

发布周期与策略

wgpu 采用双轨制发布策略：

主版本发布：每 12 周固定进行一次，无论项目当前状态如何都会执行。这种定期发布机制确保了项目的稳定迭代节奏。
补丁版本发布：在主版本之间按需进行，主要用于修复关键错误或编译问题。一旦新的主版本发布，旧版本将不再接收补丁更新，除非遇到严重问题。

这种发布策略平衡了稳定性需求与新功能迭代的速度，为用户提供了可预测的更新周期。

主版本发布流程详解

发布前准备（约1周前）

依赖项协调：

检查并确认依赖项是否需要同步更新，特别是 glow 和 metal-rs 等关键依赖
与相关维护者协调依赖项的发布时间

变更日志整理：

重新分类不正确的条目
编辑重大变更说明，确保用户能清晰理解需要进行的调整
补充遗漏的重要变更信息
整体优化变更日志的可读性和一致性

发布当日操作

版本号更新：

更新根目录的 Cargo.toml 文件中的版本号
更新所有相关位置的 wgpu 依赖版本号，包括：
- 各子模块的 Cargo.toml
- 独立示例项目

文档验证：

使用 grep 搜索旧版本号（如 v24 和 24.0），确保所有文档链接都已更新
确认 glow 和 metal 依赖已更新至最新版本（如需要）

变更日志更新：

添加新版本标题和发布日期
创建包含所有版本变更和日志更新的 PR
等待 CI 通过后合并 PR

发布执行

发布命令序列：

cargo publish -p naga
cargo publish -p naga-cli
cargo publish -p wgpu-types
cargo publish -p wgpu-hal --all-features
cargo publish -p wgpu-core-deps-apple
cargo publish -p wgpu-core-deps-emscripten
cargo publish -p wgpu-core-deps-wasm
cargo publish -p wgpu-core-deps-windows-linux-android
cargo publish -p wgpu-core --all-features
cargo publish -p wgpu
cargo publish -p wgpu-info

发布后操作：

为新发布的 crate 添加所有权
创建并推送 vX.Y.Z 标签
基于新版本创建发布说明，包含完整的变更日志
创建并推送版本分支 vX
完成当前版本的里程碑
创建下一个发布周期的里程碑（12周后）
根据需要更新发布检查清单

补丁版本发布流程

补丁发布用于快速修复问题，流程如下：

确定待移植的PR：
- 查找标记为 needs-backport 的 PR
- 在基于最新发布分支的个人分支上进行 cherry-pick 操作
- 保留原始作者信息
准备发布：
- 从已处理的 PR 中移除 needs-backport 标签
- 更新变更日志，添加补丁版本标题和日期
- 比较 HEAD 与上一个补丁版本的差异，确定需要更新的 crate
版本更新：
- 更新所有变更过的 crate 版本号
- 创建包含版本变更和日志更新的 PR 到发布分支
- 等待 CI 通过后合并
发布执行：
- 发布所有相关 crate
- 创建补丁版本发布说明和标签
- 发布说明应明确列出更新的 crate 及其版本
同步主干：
- 将变更日志和版本更新回移植到主干分支
- 确保已发布内容不会重复出现在主干的"未发布"章节中