端到端发布流程管理技能

一、技能概述

该技能是 OpenClaw 发布流程的总指挥，负责从发布分支创建到 npm publish 的完整端到端流程。它不执行 CI 验证（由 release-openclaw-ci 负责）和变更日志的源码级重写（由 openclaw-changelog-update 负责），而是负责协调、调度和决策——包括版本号决策、发布类型选择、预检执行、发布命令触发和发布后通告。

关键原则：该技能是操作者而非验证者——它执行实际的发布操作（版本 bump、npm publish、GitHub release），但这些操作必须经过明确的 operator 批准。

二、核心功能

1. 发布类型与版本号决策

技能根据 operator 的指令确定发布类型：

• 默认 Beta 发布：如果 operator 未明确说明 stable/full，默认仅执行 Beta 发布

• 版本号格式：使用 YYYY.M.PATCH，其中 PATCH 是当月顺序发布的序号，不是日历日

• Beta 版本号递增规则：

  • 从现有的稳定版/Beta 版中选择最新的 beta train，使用下一个 beta.N

  • 如果没有进行中的 beta train，则将最高的 stable/beta patch 加 1，从 beta.1 开始

  • Alpha-only tag 不消耗或不推进 beta/stable patch 号

  • 示例：2026.6.5 稳定版之后，下一个新 beta train 是 2026.6.6-beta.1，即使存在 2026.6.10-alpha.1 这样的 alpha-only tag

2. 发布分支管理

• 分支命名：从 main 切出 release/YYYY.M.PATCH 分支

• 切分支前置条件：

  • 拉取最新 main，确认当前 main CI 为绿色

  • 提交所有 dirty 文件（按逻辑分组），push、pull/rebase

  • 在 main 上生成 CHANGELOG.md（从合并的 PR 和所有直接提交），立即提交/push/pull 该变更日志，然后再创建发布分支

3. 废弃兼容性检查

在分支前和最终发布前，必须检查以下文件中的 removeAfter 日期：

• src/plugins/compat/registry.ts

• src/commands/doctor/shared/deprecation-compat.ts

对于 removeAfter 日期在发布日或之前的废弃记录：

• 如果安全，移除兼容路径并验证受影响的测试

• 如果移除被阻塞，记录原因并获得明确批准后才能发布

保留 Doctor 迁移：移除废弃的 runtime/config 兼容性时，保留任何 doctor 迁移、修复或提示，直到维护者确认不再需要

4. Beta 发布流程

• 每次 Beta 发布前：运行完整的 pre-npm 测试清单

• Beta 发布后：运行较小的 published-install 清单（install/update/Docker/Parallels）

• Beta 失败处理：

  • 如果失败，在 release 分支上修复 → commit/push/pull → 递增 beta 号 → 重复

  • Operator 可授权最多 4 次自主 beta 尝试；4 次失败后停止并报告

• Beta tag 规则：

  • 不要在 npm 包发布后删除或重写 beta tag

  • 如果 pushed beta 在 npm publish 之前失败（版本未被消费），可删除/重创或强制移动 git tag 和 prerelease 到修复的 commit，然后 rerun preflight

  • 如果已发布或 pushed 的 beta 需要修复，在 release 分支上提交修复并递增到下一个 beta.N

5. 变更日志与发布说明

• 变更日志生成：使用 /changelog 命令在 version/tag 准备之前生成，确保顶部章节去重并按用户影响排序

• Beta 使用稳定版章节：Beta 发布使用稳定版基础版本章节（例如 v2026.4.20-beta.1 使用 ## 2026.4.20 发布说明）

• 不要创建 Beta 专属标题

• README.md：不要将 README.md 编辑作为发布准备或发布说明的替代品。Package-root README 验证是硬性 packaging gate，但发布仅当实际用户可见的文档契约发生变化时才修改 README 内容

6. 发布后通告

• Discord：任何 beta 或 stable 发布上线后，尽最大努力使用 Peter 的 bot token 在 Discord 发布公告；如果公告失败，不阻塞或不回滚发布

• X（Twitter）：当被要求在 X 上发布时，使用 ~/Projects/bird/bird 并遵循发布推文风格

三、主要用途

1. Beta 版发布
   从 main 切出 release 分支，生成变更日志，执行 pre-npm 测试，发布 beta 包，运行 install 验证，并在 Discord 上公告

2. 稳定版发布
   在 Beta 验证通过后，operator 明确要求 full release 时，推进到稳定版发布

3. Beta-and-Stable 自动序列
   当 operator 要求自动化的 beta-and-stable train 时，技能可自动完成从 beta 到 stable 的全流程

4. 废弃兼容性清理
   在每个发布周期中，识别并处理已到期的废弃兼容性记录，确保代码库保持干净

5. 发布后验证与通告
   发布完成后，运行 install/update 验证，并通过 Discord/X 向社区发布公告

四、与其他技能的协作

五、重要原则

1. 版本号需明确批准：未经 explicit operator 批准，不得更改版本号

2. npm publish 需询问许可：任何 npm publish 或 release 步骤前必须询问 permission

3. Tag 本身不触发发布：Core OpenClaw publish 是 manual workflow_dispatch；创建或推送 tag 本身不会触发发布

4. 不要删除已发布的 Beta Tag：npm 包发布后，不要删除或重写 beta tag

5. 分支从 main 切出：正常发布工作在从 main 切出的分支上进行，而不是直接在 main 上

6. Changelog 在分支前生成：在创建 release 分支之前，必须在 main 上生成并提交 CHANGELOG.md

7. 废弃兼容性必须处理：每个发布周期必须检查并处理已到期的废弃兼容性记录

8. 公告失败不阻塞发布：Discord 公告失败不阻塞或不回滚发布

六、总结

Release OpenClaw Maintainer 是 OpenClaw 发布流程的核心控制技能，负责从发布分支创建、版本号决策、废弃兼容性清理、Beta/Stable 发布执行到发布后通告的完整端到端流程。它不执行 CI 验证和变更日志的源码级重写（由 release-openclaw-ci 和 openclaw-changelog-update 负责），而是作为总指挥协调所有发布环节，并在每个关键决策点（版本号变更、npm publish）要求明确的 operator 批准。该技能适用于 OpenClaw 项目维护者在每月发布周期中进行 Beta/Stable 版本发布的场景，是保障发布流程规范化、自动化和可追溯的关键技能。