From dc1ce0b2b1098f0f485bf41dd682a9912bb9bd96 Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Fri, 24 Apr 2026 01:59:49 +0100 Subject: [PATCH] docs(release): clarify beta validation flow --- .../skills/openclaw-release-maintainer/SKILL.md | 14 ++++++++++---- docs/reference/RELEASING.md | 6 ++++++ 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/.agents/skills/openclaw-release-maintainer/SKILL.md b/.agents/skills/openclaw-release-maintainer/SKILL.md index c50fe004e50..a30c43e775f 100644 --- a/.agents/skills/openclaw-release-maintainer/SKILL.md +++ b/.agents/skills/openclaw-release-maintainer/SKILL.md @@ -25,15 +25,21 @@ Use this skill for release and publish-time workflow. Keep ordinary development - Before release branching, commit any dirty files in coherent groups, push, pull/rebase, then run `/changelog` on `main` and commit/push/pull that changelog rewrite immediately before creating the release branch. +- After the release branch is cut, do not keep rebasing it onto moving `main`. + Treat the branch commit as the release base. If validation finds a concrete + issue, inspect `main` and backport only the low-risk fix commits that directly + address that failure. - 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. + focused on install/update plus all Docker and Parallels release checks. If + those published-artifact checks all pass, proceed to the non-beta release only + when the operator asked for the full beta-to-stable train. 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. - 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 diff --git a/docs/reference/RELEASING.md b/docs/reference/RELEASING.md index d0e4a50ffb0..6a863d61d61 100644 --- a/docs/reference/RELEASING.md +++ b/docs/reference/RELEASING.md @@ -35,6 +35,12 @@ OpenClaw has three public release lanes: - Maintainers normally cut releases from a `release/YYYY.M.D` branch created from current `main`, so release validation and fixes do not block new development on `main` +- After a release branch is cut, maintainers keep validating that branch instead + of rebasing after every new `main` commit. If validation finds a concrete + release issue, they may inspect `main` and backport only low-risk fixes that + directly address the failure. +- Stable follows a beta only after published-artifact validation passes, + including Docker and Parallels release checks for install/update coverage. - If a beta tag has been pushed or published and needs a fix, maintainers cut the next `-beta.N` tag instead of deleting or recreating the old beta tag - Detailed release procedure, approvals, credentials, and recovery notes are