OpenClaw¶

OpenClaw 为日常使用提供 stable 发布，为测试提供 beta 发布，并为偏好旧版 Gateway 维护线的用户提供 extended-stable 发布。本页说明这些选择以及每个发布经过的检查。如需切换渠道，请参阅发布渠道。

发布渠道¶

Extended-stable 包含 Gateway、官方 npm 插件和 Docker 镜像。它不包含原生应用或 ClawHub 发布，也不会改变常规的 stable 渠道。其 GitHub 发布不会被标记为 Latest。当某个月度线超出所支持的两个已完成月份时，该月度线即退役。

版本命名¶

版本采用 year.month.patch 格式，不进行零填充。patch 是月份内的发布编号，而不是月份中的日期。常规发布使用 33 以下的 patch；extended-stable 从 33 开始。Git 标签添加 v，如 v2026.9.6。

已发布的 npm 版本和发布标签永远不会被替换。修复会获得新版本。历史上仅限 alpha 的版本不会推进常规发布编号；alpha 发布已退役。

发布节奏¶

发布通常先进入 beta，经过验证后再进入 stable。对于 core 以及每个已发布的官方 npm 插件，beta 必须至少与 latest 一样新；如果 beta 已经更新，则保持不变。预发布版本比具有相同基础编号的最终版本更旧。

发布到 beta 渠道的最终版本仍必须满足以下稳定版验证要求。仅凭 npm 渠道本身并不能决定适用哪些检查。

发布验证¶

稳定版发布要求通过 stable 或 full 验证、更长时间的浸泡测试（soak tests）以及阻断性性能检查。这些要求同样适用于首次发布在 beta 渠道的最终版本。Beta profile 的证据不能使发布获得 stable 资格。

Full Release Validation 的常规 CI 子项（normalCi）中的 Windows Node 单元测试 CI 分片（checks-windows-node-*）对于 Release Decision 和发布而言是参考性的。windows-node-ci 类别由 scripts/full-release-validation-policy.mjs 定义；其失败仍会显示在决策、GitHub 步骤摘要和发布证据清单中。此策略不是操作员可选择的输入，也不构成豁免。普通的 PR、push、定时和 main CI 仍要求 Windows 分片通过。

所有其他选定的验证通道仍然具有阻断性：macOS Node 和其他常规 CI 任务、安装冒烟测试、survivor 通道、update-first-hop-compat*、打包/npm 资格验证、包完整性，以及所有 Linux/Windows/macOS Gateway 检查，包括 Release Checks 中的 Windows 打包安装/升级检查。被取消的运行仍然会阻断发布。发布豁免不能绕过失败或所需的覆盖范围。验证涵盖源代码 CI、包、插件、Gateway 安装与升级，以及选定的应用、UI、Telegram、QA 和 live-provider 检查。all-group 资格验证涵盖 Linux、Windows 和 macOS 上的全部九种 Gateway 安装/升级组合。其他情况下，覆盖范围因 profile 和选定的操作系统而异。请查看发布所记录的覆盖情况：跳过或延后的检查不算通过。

有关按 profile 划分的覆盖范围以及如何解读结果，请参阅 完整发布验证。

包和应用可能在不同时间可用¶

Gateway 发布并不表示所有原生应用都已就绪。应用的签名和发布可能独立于 npm、Docker 和 GitHub 发布完成。

请查看每个平台的发布资产和公告。待处理的应用构建或已接受的发布请求并不等于应用已完成发布。Extended-stable 是 Gateway 分发形式，不发布原生应用。

发布说明与验证¶

发布说明 描述了面向用户的变更。GitHub 发布还附带验证结果、依赖报告以及对已发布包的检查。这些记录标识了经过测试的版本和实际发布的文件。后续的文档更新可能会改进发布说明，但不会重新构建或替换包。

有关依赖审查，请参阅 依赖锁定。发布依赖归档包含 npm 格式的锁文件，与包 tarball 分开提供。

下游打包¶

若要使用发布锁文件：

1. 从 GitHub 发布中下载 openclaw-<version>-dependency-evidence.zip。打开 dependency-evidence/npm-package-locks.json（schemaVersion: 1），选择与精确包 name 和 version 匹配的 packages 条目。
2. 拒绝带有非空 omittedWorkspaceDependencies 数组的条目。这些是部分锁：生成器会省略在同一发布中发布的同级 workspace: 运行时依赖。报告会将这些条目计入 packagesWithOmittedWorkspaceDependencies。
3. 验证 dependency-evidence/dependency-evidence-manifest.json 的 releaseSha、报告的 sourceSha 以及你所固定的 OpenClaw 提交是否全部匹配。报告还会记录源 pnpm-lock.yaml 的 SHA-256。
4. 将 entry.lock 序列化为 package-lock.json，使用双空格 JSON 缩进并以换行符结尾，然后将其 SHA-256 与 entry.lockSha256 进行核对。
5. 在执行 npm ci 之前，将源 pnpm-workspace.yaml 的覆盖项带入使用方的 package.json，或将嵌套的 dependencies 和 optionalDependencies 声明重写为其锁定的版本。生成的锁文件编码了 workspace 覆盖项，因此未经修改的声明可能会导致 npm 的锁同步检查失败。

配套的 npm-package-locks.md 包含计数和一个包表格。每个条目都会记录 bundleRuntimeDependencies 和直接依赖项计数，以便打包者识别需要外部锁的无锁包。每个条目还记录了一个按路径排序的 bundledDependencies 数组，其中包含 path、name、version 和 parent。这些依赖项在 npm 锁中带有 inBundle: true；parent 标识最近的外层非捆绑包，其 resolved 和 integrity 用于验证承载这些字节的 tarball。该报告会拒绝缺失或无法验证的载体，并保留锁负载。Markdown 表格统计每个包的捆绑依赖项数量，并包含其总数。

维护者流程¶

发布准备、发布命令、审批和恢复流程均位于 release-maintainer skill 中。凭据处理和紧急流程仍保留在私有维护者运行手册中。下方的原章节链接指向相应的流程。

Linux 发布。

发布变更日志。

仅变更日志资格认证。

扩展稳定版的准备与发布。

扩展稳定版恢复。

常规发布清单。

可恢复的发布编排。

延迟 CI 恢复。

夜间验证复用。

发布工具 CI 范围。

稳定主分支收尾。

发布后文档发布。

源码与包门禁。

旧版更新程序验证。

运行时世代设计提案（非已发布行为）。

发布验证通道。

包验收。

发布资格认证。

Bootstrap-token 验证。

预先准备的发布。

中断的准备与发布。

已发布版本恢复。

常规发布与验证.

发布要求.

发布工作流参考.