release-management

发布管理技能

发布由 release-please 管理，统一使用带有“v”前缀的版本号。

工作原理

1. 推送到 main 的提交会触发 .github/workflows/release.yml
2. release-please 会分析自上次发布以来的 Conventional Commits
3. 它会创建或更新一个标题为 chore: release v{version} 的 Release PR，该 PR 会更新每个 package.json，并将新条目添加到 CHANGELOG.md 的开头
4. 合并 Release PR 之前不会发布任何内容；由 Claude 决定何时合并（见下文）
5. 合并后会创建 v{version} 标签和 GitHub Release

feat 会提升次版本号，fix 和 perf 会提升补丁版本号，feat! 或 BREAKING CHANGE 页脚会提升主版本号。

何时合并 Release PR

此决策由 Claude 负责，而不是 Ru。每当功能 PR 合并时，以及在分诊期间，都要检查未合并的 Release PR，并在符合以下条件时合并。

符合以下条件时合并：

• 至少包含一个 feat，或者
• 仅包含 fix 或 perf，且已打开 7 天或更久

符合以下条件时暂缓：

• main 的最新生产部署失败，或其中某项内容的回滚正在等待处理
• Release PR 修改了 CHANGELOG.md、.release-please-manifest.json 和 version 字段之外的任何内容；此时应进行调查

以下情况先询问 Ru：

• 这是一次主版本号更新（feat! 或 BREAKING CHANGE 页脚）

使用 gh pr merge <number> --squash 合并，以便 main 获得一个 chore: release v{version} 提交。之后报告版本号和 PR 链接。

版本方案

• 格式：v{major}.{minor}.{patch}（例如，v5.31.0）
• 整个 monorepo 统一使用同一版本号
• 标签不带组件前缀（include-component-in-tag: false）

配置

• release-please-config.json：根 package 使用 release-type: node，并将每个工作区的 package.json 列在 extra-files 下，以便它们与根目录使用相同的版本号
• .release-please-manifest.json：当前版本号；release-please 会在每个 Release PR 中更新它

新工作区 package 需要添加 extra-files 条目，否则其版本号会偏离。

检查发布状态

# View the open Release PR
gh pr list --label "autorelease: pending"

# View recent releases
gh release list --limit 5

# Check release workflow status
gh run list --workflow=release.yml --limit 5

调试

没有 Release PR

• 只有 feat、fix、perf 和包含破坏性变更的提交会触发发布；chore、docs 等不会触发
• 检查工作流是否运行：gh run list --workflow=release.yml

Release PR 没有检查项

• 使用 GITHUB_TOKEN 创建的 PR 不会触发其他工作流，因此 Release PR 不会运行 PR 检查。 它只会修改版本号和更新日志

强制指定版本

• 添加带有 Release-As: x.y.z 页脚的提交，或在 release-please-config.json 中设置 release-as

相关内容

• 更新日志详情请参阅 changelog 技能
• 发布回滚请参阅 deployment-rollback 技能
• 工作流：.github/workflows/release.yml