From b7733c48c06c2c7323e2b5a7a5db99c8a97ef85d Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Sun, 26 Apr 2026 09:58:34 +0100 Subject: [PATCH] docs(release): codify beta train backport scan --- .../openclaw-release-maintainer/SKILL.md | 35 ++++++++++++------- 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/.agents/skills/openclaw-release-maintainer/SKILL.md b/.agents/skills/openclaw-release-maintainer/SKILL.md index 1fe4de534ae..a70f6d9b81c 100644 --- a/.agents/skills/openclaw-release-maintainer/SKILL.md +++ b/.agents/skills/openclaw-release-maintainer/SKILL.md @@ -28,12 +28,17 @@ Use this skill for release and publish-time workflow. Keep ordinary development - Do not delete or rewrite beta tags after they leave the machine. If a published or pushed beta needs a fix, commit the fix on the release branch and increment to the next `-beta.N`. -- For a beta release train, run the full pre-npm test roster before publishing - each beta. After a beta is published, run the smaller published-install roster - focused on install/update/Docker/Parallels. If anything fails, fix it on the - release branch, commit/push/pull, increment beta number, and repeat. Operators - may authorize up to 4 autonomous beta attempts; after 4 failed beta attempts, - stop and report. +- For a beta release train, run the fast local preflight first, publish the + beta to npm `beta`, then run the expensive published-package roster focused + on install/update/Docker/Parallels/NPM Telegram. If anything fails, fix it on + the release branch, commit/push/pull, increment beta number, and repeat. Run + the full expensive roster at least once before stable/latest promotion; for + later beta attempts, rerun only lanes whose evidence changed unless the fix + touches broad release, install/update, plugin, Docker, Parallels, or live QA + behavior. After each beta is published, scan current `main` once for critical + fixes that landed after the release branch cut and backport only important + low-risk fixes. Operators may authorize up to 4 autonomous beta attempts; + after 4 failed beta attempts, stop and report. - Use `/changelog` before version/tag preparation so the top changelog section is deduped and ordered by user impact. - Do not create beta-specific `CHANGELOG.md` headings. Beta releases use the @@ -491,8 +496,10 @@ node --import tsx scripts/openclaw-npm-postpublish-verify.ts 6. Create `release/YYYY.M.D` from that post-changelog `main` commit. 7. Make every repo version location match the beta tag before creating it. 8. Commit release preparation changes on the release branch and push the branch. -9. Run the local build, Docker, and Parallels parts of the full pre-npm beta - test roster from the release branch before any npm preflight or publish. +9. Run the fast local beta preflight from the release branch before any npm + preflight or publish. Keep expensive Docker, Parallels, and published-package + install/update lanes for after the beta is live unless the operator asks to + run them before beta publication. 10. For beta releases, skip mac app build/sign/notarize unless beta scope or a release blocker specifically requires it. For stable releases, include the mac app, signing, notarization, and appcast path. @@ -529,10 +536,14 @@ node --import tsx scripts/openclaw-npm-postpublish-verify.ts 21. Wait for `npm-release` approval from `@openclaw/openclaw-release-managers`. 22. Run postpublish verification: `node --import tsx scripts/openclaw-npm-postpublish-verify.ts `. -23. Run the post-published beta verification roster. If any lane fails after - the beta tag/package is pushed or published, fix, commit/push/pull, - increment to the next beta tag, and restart at the full pre-npm beta test - roster for the new beta. The roster includes the manual Actions > +23. Run the post-published beta verification roster. First scan current `main` + for critical fixes that landed after the release branch cut; backport only + important low-risk fixes before starting expensive lanes, or increment to + the next beta if the fix must change the already-published package. If any + lane fails after the beta tag/package is pushed or published, fix, + commit/push/pull, increment to the next beta tag, and rerun the affected + beta evidence. Ensure the full expensive roster has passed at least once + before stable/latest promotion. The roster includes the manual Actions > `NPM Telegram Beta E2E` workflow against the exact published beta package. If a pre-npm lane fails before any tag/package leaves the machine, fix and rerun the same intended beta attempt. Repeat up to the operator's