OmniRoute 发布清单实操指南版本号升级、变更日志与发布前自动化检查全流程【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本篇以 OmniRoute 仓库的 RELEASE_CHECKLIST.md英文主版见 docs/ops/RELEASE_CHECKLIST.md为主线梳理每次打 tag 或发布新版本前必须完成的版本管理、API 文档同步、运行时文档审查与自动化检查步骤。读完你可以掌握 OmniRoute 从 bump 版本号到提交 PR 的标准化发布流程并理解每条清单背后的仓库实现依据。版本与变更日志管理发布的第一步永远是定版本、理日志。清单要求按顺序执行以下动作在 release 分支中升级package.json的版本号格式为x.y.z语义化版本将CHANGELOG.md中## [Unreleased]之下的发布说明迁移到一个带日期的章节即## [x.y.z] — YYYY-MM-DD保持## [Unreleased]作为变更日志的第一个章节供下一轮迭代继续累积确保CHANGELOG.md中最新的 semver 章节号与package.json的 version 字段完全一致。在仓库中可以验证这套约定的实际落点根 package.json 当前版本为3.8.51CHANGELOG.md 首部即为## [Unreleased]章节随后才是已发布的版本记录。若你在 release 分支上git log生成提交列表需要人工复核提交信息并按功能归类因为变更日志的可读性直接影响下游使用者与搜索引擎对版本差异的理解。API 文档同步版本号变更并非只在package.json一处生效API 契约也必须对齐更新docs/openapi.yaml其中info.version必须等于package.json的版本号若 API 契约端点、参数、响应结构在本轮发生了变更需逐一校验 openapi 文档中的端点示例仍然可用。仓库根目录下存在 docs/openapi.yaml它是公开的 API 描述文件根目录另有 public/openapi.yaml 供前端侧引用。发布时若两者都涉及版本信息应一并核对。实践建议将版本号已同步与端点示例可跑通作为两项独立勾选避免只改字段、漏验契约。运行时文档审查每次发布还要排查运行时事实与文档是否漂移审查 docs/architecture/ARCHITECTURE.md确认其中对存储层与运行时的描述没有过时审查 docs/guides/TROUBLESHOOTING.md确认环境变量与运维相关的描述没有漂移验证发布/运行所要求的 Node.js 版本仍满足官方支持的安全下限清单给出的安全下限为20.20.2 21或22.22.2 23运行npm run check:node-runtime自动核验构建独立发布包后校验 npm 发布产物npm run build:clinpm run check:pack-artifact确认产物中不残留app.__qa_backup、scripts/scratch、package-lock.json等本地开发痕迹若英文源文档改动较大同步更新本地化i18n文档。关于 Node 版本门槛仓库实现比清单更精确src/shared/utils/nodeRuntimeSupport.ts 中定义了SUPPORTED_NODE_RANGE 22.22.2 23 || 24.0.0 27SECURE_NODE_LINES列出了 22.22.2、24.0.0、25.0.0、26.0.0 四个安全基线且该模块被运行时 CLI 入口bin/、Next.js 路由处理器src/与仓库脚本scripts/共用。根 package.json 的engines字段与之一致。也就是说随着版本演进清单中的下限已从 20.x 时代升级到当前以 22.22.2 / 24.0.0 为准发布时以npm run check:node-runtime的实际校验结果为准即可。npm run check:pack-artifact对应 scripts/build/validate-pack-artifact.ts它扫描打包目录中是否混入本地残留文件——这正是干净产物检查的实现载体。发布前的自动化同步检查在打开 PR 之前必须在本地运行文档同步守卫npm run check:docs-sync该命令对应 scripts/check/check-docs-sync.mjs。它的核心职责是校验 i18n 翻译文档树与英文源文档一一对应、无漂移——这正是本文所引用的docs/i18n/it/docs/ops/RELEASE_CHECKLIST.md这类翻译文件存在的意义。此外CI 的 lint job 也会在 .github/workflows/ci.yml 中再次运行同一检查形成本地先行、CI 兜底的双保险。提交时它还会被 Husky 的 pre-commit 钩子自动触发见 .husky/pre-commit所以即使忘了手动执行提交阶段也会被拦截提醒。纵深完整发布流程的关键关卡除上述四步外英文主版清单还细化了从发布前到回滚的完整关卡可作为深度执行的参考发布前确认目标 PR 全部合入release/vX.Y.0、CI 在 release 分支上全绿、代码中无TODO(release)残留并确认 Docker 基础镜像已更新代码质量npm run lint零错误、typecheck:core与typecheck:noimplicit:core干净、check:cycles无循环依赖、check:any-budget:t11与check:route-validation:t06在预算内、check:node-runtime通过这些命令全部登记在根 package.json 的 scripts 中测试矩阵test:unit、test:vitest、test:coverage门槛 60/60/60/60即 statements/lines/functions/branches 四维覆盖、test:integration、test:combo:matrix、test:e2e、test:protocols:e2e、test:ecosystem等按改动面执行其中 package.json 中test:coverage通过 c8 以--check-coverage --statements 60 --lines 60 --functions 60 --branches 60强制执行门槛Husky 钩子pre-commit 运行 lint-staged、docs-sync 与预算检查pre-push 运行确定性快门check:any-budget:t11与check:tracked-artifacts。钩子失败必须修复根因禁止--no-verify绕过Conventional Commits所有发布提交必须符合type(scope): subject格式类型限于feat/fix/refactor/docs/test/chore/perf/style/ci破坏性变更需附加BREAKING CHANGE:脚注或在 scope 后加!构建布局仓库使用三套输出目录——src/TypeScript/TSX 源码入库、.build/next build 中间产物gitignore、dist/可发布的 npm 包由assembleStandalone汇总gitignore。发布部署统一走npm run build:release先清空.build与dist再 next build、组装 standalone、写入dist/BUILD_SHA不要拆成npm run buildnpm run build:cli两段执行工件校验dist/BUILD_SHA必须等于git rev-parse --short HEADcheck:pack-artifact无残留dist/server.js存在打标签与发布通过/generate-release-ccskill 创建并推送vX.Y.Ztag、打开带 changelog 正文的 Release或手工执行git tag -a vX.Y.Z -m Release vX.Y.Z、git push origin vX.Y.Z、gh release create vX.Y.Z --notes-from-tag部署与冒烟部署 skill 采用轻量 rsync 流程不打 npm pack、不全局安装部署后打开/dashboard/health核对版本字符串、对已知 provider 发一次/v1/chat/completions请求、确认/api/monitoring/health的熔断器为CLOSED、并验证 MCP 传输端点响应回滚与硬规则发布异常时先gh release edit vX.Y.Z --prerelease标记非最新未广泛采纳时可删除 tag否则在 release 分支上打 patch 热修。硬规则包括禁止直接提交main、禁止强推main/release/*、禁止跳过 Husky、禁止提交密钥与.env、覆盖率始终 ≥60/60/60/60、改动src/、open-sse/、electron/、bin/必须同步更新测试。小结OmniRoute 的发布清单把版本号—变更日志—API 文档—运行时事实—产物干净度串成一条可验证的流水线本地npm run check:docs-sync与 Husky 钩子保证提交即合规CI 的 lint job 再次兜底而 Node 运行时门槛、打包残留扫描、覆盖率四维门槛则分别在 src/shared/utils/nodeRuntimeSupport.ts、scripts/build/validate-pack-artifact.ts 与 package.json 的test:coverage配置中落地。对任何准备为 OmniRoute 提发布 PR 的贡献者而言照此清单逐项勾选即可获得一条开箱即绿的发布路径。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OmniRoute 发布清单实操指南：版本号升级、变更日志与发布前自动化检查全流程
OmniRoute 发布清单实操指南版本号升级、变更日志与发布前自动化检查全流程【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本篇以 OmniRoute 仓库的 RELEASE_CHECKLIST.md英文主版见 docs/ops/RELEASE_CHECKLIST.md为主线梳理每次打 tag 或发布新版本前必须完成的版本管理、API 文档同步、运行时文档审查与自动化检查步骤。读完你可以掌握 OmniRoute 从 bump 版本号到提交 PR 的标准化发布流程并理解每条清单背后的仓库实现依据。版本与变更日志管理发布的第一步永远是定版本、理日志。清单要求按顺序执行以下动作在 release 分支中升级package.json的版本号格式为x.y.z语义化版本将CHANGELOG.md中## [Unreleased]之下的发布说明迁移到一个带日期的章节即## [x.y.z] — YYYY-MM-DD保持## [Unreleased]作为变更日志的第一个章节供下一轮迭代继续累积确保CHANGELOG.md中最新的 semver 章节号与package.json的 version 字段完全一致。在仓库中可以验证这套约定的实际落点根 package.json 当前版本为3.8.51CHANGELOG.md 首部即为## [Unreleased]章节随后才是已发布的版本记录。若你在 release 分支上git log生成提交列表需要人工复核提交信息并按功能归类因为变更日志的可读性直接影响下游使用者与搜索引擎对版本差异的理解。API 文档同步版本号变更并非只在package.json一处生效API 契约也必须对齐更新docs/openapi.yaml其中info.version必须等于package.json的版本号若 API 契约端点、参数、响应结构在本轮发生了变更需逐一校验 openapi 文档中的端点示例仍然可用。仓库根目录下存在 docs/openapi.yaml它是公开的 API 描述文件根目录另有 public/openapi.yaml 供前端侧引用。发布时若两者都涉及版本信息应一并核对。实践建议将版本号已同步与端点示例可跑通作为两项独立勾选避免只改字段、漏验契约。运行时文档审查每次发布还要排查运行时事实与文档是否漂移审查 docs/architecture/ARCHITECTURE.md确认其中对存储层与运行时的描述没有过时审查 docs/guides/TROUBLESHOOTING.md确认环境变量与运维相关的描述没有漂移验证发布/运行所要求的 Node.js 版本仍满足官方支持的安全下限清单给出的安全下限为20.20.2 21或22.22.2 23运行npm run check:node-runtime自动核验构建独立发布包后校验 npm 发布产物npm run build:clinpm run check:pack-artifact确认产物中不残留app.__qa_backup、scripts/scratch、package-lock.json等本地开发痕迹若英文源文档改动较大同步更新本地化i18n文档。关于 Node 版本门槛仓库实现比清单更精确src/shared/utils/nodeRuntimeSupport.ts 中定义了SUPPORTED_NODE_RANGE 22.22.2 23 || 24.0.0 27SECURE_NODE_LINES列出了 22.22.2、24.0.0、25.0.0、26.0.0 四个安全基线且该模块被运行时 CLI 入口bin/、Next.js 路由处理器src/与仓库脚本scripts/共用。根 package.json 的engines字段与之一致。也就是说随着版本演进清单中的下限已从 20.x 时代升级到当前以 22.22.2 / 24.0.0 为准发布时以npm run check:node-runtime的实际校验结果为准即可。npm run check:pack-artifact对应 scripts/build/validate-pack-artifact.ts它扫描打包目录中是否混入本地残留文件——这正是干净产物检查的实现载体。发布前的自动化同步检查在打开 PR 之前必须在本地运行文档同步守卫npm run check:docs-sync该命令对应 scripts/check/check-docs-sync.mjs。它的核心职责是校验 i18n 翻译文档树与英文源文档一一对应、无漂移——这正是本文所引用的docs/i18n/it/docs/ops/RELEASE_CHECKLIST.md这类翻译文件存在的意义。此外CI 的 lint job 也会在 .github/workflows/ci.yml 中再次运行同一检查形成本地先行、CI 兜底的双保险。提交时它还会被 Husky 的 pre-commit 钩子自动触发见 .husky/pre-commit所以即使忘了手动执行提交阶段也会被拦截提醒。纵深完整发布流程的关键关卡除上述四步外英文主版清单还细化了从发布前到回滚的完整关卡可作为深度执行的参考发布前确认目标 PR 全部合入release/vX.Y.0、CI 在 release 分支上全绿、代码中无TODO(release)残留并确认 Docker 基础镜像已更新代码质量npm run lint零错误、typecheck:core与typecheck:noimplicit:core干净、check:cycles无循环依赖、check:any-budget:t11与check:route-validation:t06在预算内、check:node-runtime通过这些命令全部登记在根 package.json 的 scripts 中测试矩阵test:unit、test:vitest、test:coverage门槛 60/60/60/60即 statements/lines/functions/branches 四维覆盖、test:integration、test:combo:matrix、test:e2e、test:protocols:e2e、test:ecosystem等按改动面执行其中 package.json 中test:coverage通过 c8 以--check-coverage --statements 60 --lines 60 --functions 60 --branches 60强制执行门槛Husky 钩子pre-commit 运行 lint-staged、docs-sync 与预算检查pre-push 运行确定性快门check:any-budget:t11与check:tracked-artifacts。钩子失败必须修复根因禁止--no-verify绕过Conventional Commits所有发布提交必须符合type(scope): subject格式类型限于feat/fix/refactor/docs/test/chore/perf/style/ci破坏性变更需附加BREAKING CHANGE:脚注或在 scope 后加!构建布局仓库使用三套输出目录——src/TypeScript/TSX 源码入库、.build/next build 中间产物gitignore、dist/可发布的 npm 包由assembleStandalone汇总gitignore。发布部署统一走npm run build:release先清空.build与dist再 next build、组装 standalone、写入dist/BUILD_SHA不要拆成npm run buildnpm run build:cli两段执行工件校验dist/BUILD_SHA必须等于git rev-parse --short HEADcheck:pack-artifact无残留dist/server.js存在打标签与发布通过/generate-release-ccskill 创建并推送vX.Y.Ztag、打开带 changelog 正文的 Release或手工执行git tag -a vX.Y.Z -m Release vX.Y.Z、git push origin vX.Y.Z、gh release create vX.Y.Z --notes-from-tag部署与冒烟部署 skill 采用轻量 rsync 流程不打 npm pack、不全局安装部署后打开/dashboard/health核对版本字符串、对已知 provider 发一次/v1/chat/completions请求、确认/api/monitoring/health的熔断器为CLOSED、并验证 MCP 传输端点响应回滚与硬规则发布异常时先gh release edit vX.Y.Z --prerelease标记非最新未广泛采纳时可删除 tag否则在 release 分支上打 patch 热修。硬规则包括禁止直接提交main、禁止强推main/release/*、禁止跳过 Husky、禁止提交密钥与.env、覆盖率始终 ≥60/60/60/60、改动src/、open-sse/、electron/、bin/必须同步更新测试。小结OmniRoute 的发布清单把版本号—变更日志—API 文档—运行时事实—产物干净度串成一条可验证的流水线本地npm run check:docs-sync与 Husky 钩子保证提交即合规CI 的 lint job 再次兜底而 Node 运行时门槛、打包残留扫描、覆盖率四维门槛则分别在 src/shared/utils/nodeRuntimeSupport.ts、scripts/build/validate-pack-artifact.ts 与 package.json 的test:coverage配置中落地。对任何准备为 OmniRoute 提发布 PR 的贡献者而言照此清单逐项勾选即可获得一条开箱即绿的发布路径。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考