Release Preparation

Release preparation

Use this playbook only to prepare a version-release pull request. Do not expand the scope into compatibility, packaging, documentation-site, or publication work unless the user explicitly requests it.

Determine the release

1. Read the current version in package.json and the Unreleased sections in CHANGELOG.md and CHANGELOG_EN.md.
2. If the target version is explicit, use it. Otherwise ask for it; for release-only fixes, recommend the next patch version.
3. Preserve every Unreleased entry. Do not add a changelog entry unless repository policy specifically requires one for this developer tooling.

Change only release metadata

Use one identical version and date in exactly these five files:

• package.json
• package-lock.json: the top-level version and packages[""].version
• openclaw.plugin.json
• CHANGELOG.md
• CHANGELOG_EN.md

Move each changelog's existing Unreleased content beneath its matching dated release heading, leaving an empty Unreleased heading in each file. Do not change the plugin/channel identity, minimum-host metadata, dependency versions, or unrelated content.

Validate and hand off

By default, run only:

npm run check:versions
node scripts/render-release-notes.mjs
git diff -- package.json package-lock.json openclaw.plugin.json CHANGELOG.md CHANGELOG_EN.md

Do not run npm ci, npm run check, host compatibility matrices, npm run pack:check, or documentation-site builds for a metadata-only release. Run broader checks only when explicitly requested or when the actual diff extends beyond release metadata; the CI pipeline validates pull-request compatibility.

Commit the prepared changes, push the branch, and open a release pull request using .github/pull_request_template.md. Never create or move tags, publish packages, approve protected environments, or trigger any irreversible release operation. Merge-time CI owns tagging and coordinated publication.