ONNX Runtime WebGPU 插件 EP 发布流程按次版本划分支、命名空间标签与三阶段 Release 工作流【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime本篇基于 ONNX Runtime 仓库中 plugin-ep-webgpu/RELEASE.md 的发布规范展开完整覆盖 WebGPU 插件执行提供程序Plugin EP的语义化版本管理、plugin-ep-webgpu/前缀的分支与标签命名规则、与主 ORT 发布惯例的差异以及准备分支—构建验证—正式发布的三步工作流。读完之后你能够按照仓库约定独立完成一次 patch 或 minor 版本发布并理解 CI 管道中版本号的自动派生机制。发布对象WebGPU 插件 EP 是什么在讨论发布流程之前先明确发布的是哪个东西。WebGPU 插件 EP 是独立于主onnxruntime二进制分发的执行提供程序它被主 ONNX Runtime 构建以--use_webgpu shared_lib产出为共享库onnxruntime_providers_webgpu.{dll,so,dylib}再由 plugin-ep-webgpu 目录下的打包源打成各平台的 Python wheelonnxruntime-ep-webgpu源在 plugin-ep-webgpu/python跨平台的 NuGet 包Microsoft.ML.OnnxRuntime.EP.WebGpu源在 plugin-ep-webgpu/csharp供 Foundry Local 消费的分平台 zip 包。因此一次插件 EP 发布最终体现为多个包制品但版本控制只需要围绕一组文件展开这就是本规范保持简洁的前提。版本管理语义化版本与 VERSION_NUMBER 文件插件 EP 遵循语义化版本Semantic Versioning三个分量的含义在 RELEASE.md 中定义如下MAJOR— 不兼容的 API/ABI 变更MINOR— 向后兼容的功能新增PATCH— 向后兼容的缺陷与安全修复。当前版本号追踪在 plugin-ep-webgpu/VERSION_NUMBER 文件中仓库现状为0.4.0。该文件是 CI 管道的基础版本单一事实来源管道根据构建参数release / dev从中派生出最终包版本。与之配套的是 plugin-ep-webgpu/MIN_ONNXRUNTIME_VERSION当前为1.24.4它声明了兼容的核心onnxruntime最低版本。按 plugin-ep-webgpu/README.md 的说明各包并不对某个具体 ORT 包声明硬依赖而是把这个版本串在打包时注入各包 README并由原生插件 EP 代码在注册时做运行时兼容性校验。从 tools/ci_build/set_plugin_ep_build_variables.py 的源码可以看到版本号派生的具体规则package_versionrelease时包版本与 Python 版本都直接等于VERSION_NUMBER的内容如0.4.0package_versiondev时管道通过git rev-parse --short8 HEAD和 commit 的 UTC 时间戳生成形如0.4.0.devYYYYMMDDHHMMSSPEP 440 格式与0.4.0-dev.YYYYMMDDHHMMSSshasemver 格式的开发版本串并用两个正则分别校验 semver 2.0.0 与 PEP 440 合法性后才写入管道变量package_versionrc目前会直接让构建失败并提示 RC versioning is not yet implemented。这一点与 RELEASE.md 中pre-release 标签约定是前瞻性forward-looking的目前发布流程还没有 release candidate的表述完全吻合——约定先定好实现随后跟上。分支与标签命名命名空间 前缀双保险所有发布 ref 都统一置于plugin-ep-webgpu/命名空间下这样它们在git branch/git tag列表中聚成一组也不会和主 ONNX Runtime 的发布 ref 冲突。具体有三类Release 分支plugin-ep-webgpu/rel-X.Y每个 minor 版本线一个分支例如plugin-ep-webgpu/rel-1.0承载该 minor 线上的所有 patch 发布1.0.0、1.0.1、1.0.2、……在首次发布时从main分叉出来。Release 标签plugin-ep-webgpu/vX.Y.Z每次实际发布的产物打一个标签例如plugin-ep-webgpu/v1.0.0标签不可变immutable是到底发布了什么的事实来源source of truth。Pre-release 标签plugin-ep-webgpu/vX.Y.Z-rc.N用于 release candidate 及其他预发布制品采用 semver 风格的后缀目前为前瞻性约定流程中尚无 RC 环节与上文的 RC 未实现状态对应。一个细节值得注意分支用rel-前缀、标签用v前缀两者在 ref 层级上永远不会产生歧义——即使同一条 minor 线上既有rel-1.0分支又有v1.0.0标签也不会互相覆盖或混淆。与主 ONNX Runtime 惯例的差异为什么按 minor 划分支主 ORT 仓库采用的是按 patch划分的发布分支形式为rel-X.Y.Z例如rel-1.20.0、rel-1.20.1每个 patch 一个分支。WebGPU 插件 EP 则刻意选择了按 minor划分的rel-X.YRELEASE.md 给出了两条理由简单性每条受支持的 minor 线只有一个长生命周期分支每次 patch 发布用该分支上的一个标签来标记。标签是不可变的发布记录分支只是下一个 patch 的暂存处。对于一个体量、发布节奏都有限的组件这套模型足够用还能避免按 patch 模型造成的分支蔓延branch sprawl。通用惯例per-minor 模型是更广泛的开源社区惯例Linux、LLVM、Python、Node、Kubernetes 都如此ORT 生态之外的贡献者会感到熟悉。再加上plugin-ep-webgpu/命名空间前缀插件的发布 ref 与主 ORT 的发布 ref 就保持了清晰的隔离。可以推断这套设计的核心思想是把可变分支与不可变标签的职责拆开并让命名空间承担与主线发布的隔离职责。发布工作流三步走第一步准备发布分支按发布类型走对应的子流程原文 RELEASE.md 的 Step 1新的 minor 或 major 发布从main创建发布分支plugin-ep-webgpu/rel-X.Y。此时main上的VERSION_NUMBER应已经是X.Y.0即反映即将切出的那个发布把main上的VERSION_NUMBER提升到下一个开发版本例如切1.0.0后把main提升到1.1.0。Patch 发布在既有发布分支plugin-ep-webgpu/rel-X.Y上把VERSION_NUMBER提升到X.Y.Z。可以看到版本号的管理完全集中在 plugin-ep-webgpu/VERSION_NUMBER 这一个文件上main上永远指向下一个 minor 的 .0各 release 分支上则滚动指向最新 patch。第二步集成修复、构建并验证包这一步可循环执行多次直到满意为止原文 Step 2把修复集成进发布分支——可以从maincherry-pick也可以直接在发布分支上做。后者除非是发布分支特有的修复否则应回灌到main在发布分支的 tip 上运行打包管道WebGPU Plugin EP Packaging Pipeline管道定义见 tools/ci_build/github/azure-pipelines/plugin-webgpu-pipeline.yml。确认紧随其后的打包测试管道WebGPU Plugin EP Test Pipeline定义见 tools/ci_build/github/azure-pipelines/plugin-webgpu-test-pipeline.yml运行成功。打包管道成功后会自动触发测试管道——两者刻意分离源码注释解释为这样测试侧Dockerfile、Vulkan 配置、测试脚本可以独立迭代而不必重新从源码构建 Dawn/WebGPU可选运行发布管道发布测试版包做预演。NuGet 发布管道支持把PublishLocation参数设为 nugettestint.nugettest.org或 adoADO nightly feed。原文特别警告该管道同样用于发布到 nuget.org运行前务必二次确认PublishLocation取值Python 测试发布则固定发布到 ADO nightly feed按需执行其他人工验证。结合管道定义文件第二步还有一些值得了解的工程细节打包管道支持五个平台的独立开关build_windows_x64、build_windows_arm64、build_linux_x64、build_linux_aarch64、build_macos_arm64默认全部开启package_version参数可选release/dev源码中# - RC # not implemented yet被注释掉默认dev管道内置参数校验非dev的包版本必须搭配Release的 CMake 构建类型否则在 Validate_Parameters 阶段直接报错失败Non-dev package version requires Release build type除手动触发外打包管道还有每日 09:00UTC的 nightly 计划任务仅在main相对上次成功构建有源码变更时执行版本号派生步骤通过 tools/ci_build/github/azure-pipelines/templates/set-plugin-ep-build-variables-step.yml 调用前述 Python 脚本完成epVersionFile变量即指向plugin-ep-webgpu/VERSION_NUMBER。另外plugin-ep-webgpu/paths.txt 定义了与 WebGPU EP 相关的路径清单如onnxruntime/core/providers/webgpu、plugin-ep-webgpu等CI 用它在识别两次发布之间发生了什么变更例如生成 release notes时过滤提交——这也是发布流程的一部分工具。第三步正式发布原文Step 3的最终动作序列是运行打包管道并把Package Version参数设为release这次运行产出的就是 release 构建运行发布管道发布正式包注意要把第 1 项的 release 构建选为源打包管道运行NuGet 发布时PublishLocation设为 nugetPython 发布走对应的 Python publishing 管道在产出 release 构建的那个 commit上给发布分支打上标签plugin-ep-webgpu/vX.Y.Z——同一个 commit是关键保证标签精确指向实际发布的代码在该标签上创建一个 GitHub release。第 3 步呼应了命名约定中的原则标签是不可变记录因此一旦打完vX.Y.Z就不能再动后续同一 minor 线上的下一个 patch则回到第一步patch 分支上提升VERSION_NUMBER重新走完整流程。小结这套发布约定给了什么回到 plugin-ep-webgpu/RELEASE.md 的规范本身它用很少的篇幅约定了三件事并与仓库中的实现证据一一对应版本semver 三分量 单一VERSION_NUMBER文件现值0.4.0CI 依据 tools/ci_build/set_plugin_ep_build_variables.py 派生出 release/dev 两种包版本串RC 约定先行、实现待补命名plugin-ep-webgpu/命名空间 rel-X.Y按 minor 分支 vX.Y.Z不可变标签与主 ORT 的按 patch 分支模型显式解耦流程准备分支 → 可循环的构建/测试验证含发布测试版预演与PublishLocation防误操作提醒→ release 构建 发布 同 commit 打标签 GitHub release。对于维护者而言按此约定操作即可保证任何一次发布都能通过标签 命名空间 VERSION_NUMBER三要素被精确定位和追溯对于使用者而言这些标签就是判断我装的包是从哪份代码构建出来的唯一可靠依据。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考