vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-08-02 08:21:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: require changelog before extended-stable preflight (#112533)

Browse Source
This commit is contained in:
Dallin Romney
2026-07-23 10:35:57 +09:00
committed by GitHub
parent 6c5713b6f1
commit 2aed598705
2 changed files with 29 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
.agents/skills/release-openclaw-maintainer/SKILL.md
View File

@@ -237,13 +237,17 @@ Docker Gateway images. Treat
on pinned current `main` as the exact command and validation contract.
1. Check out the canonical `extended-stable/YYYY.M.33` branch after the
approved backport PR lands. Freeze its full 40-character SHA after verifying
the root and every publishable official plugin have the intended version.
Backport the complete current-main Docker release-channel change, including
its workflow, promoter, policy, shared release-version classifier, tests,
and workflow validation changes. Do not tag yet; tag-push workflows use
that code, which must not route `.33+` to regular stable aliases or fail
from a partial copy.
approved backport PR lands. Verify the root and every publishable official
plugin have the intended version, then generate and commit the complete
`## YYYY.M.P` `CHANGELOG.md` section before freezing its full 40-character
SHA. Unlike the regular Code-SHA flow, this npm-only candidate preflight
packages the frozen tree, so a matching non-empty changelog section is a
prerequisite, not post-validation release decoration. Backport the complete
current-main Docker release-channel change, including its workflow, promoter,
policy, shared release-version classifier, tests, and workflow validation
changes. Do not create the final tag yet; tag-push workflows use that code,
which must not route `.33+` to regular stable aliases or fail from a partial
copy.
2. Dispatch `openclaw-npm-release.yml` from that canonical branch with the
frozen SHA as `tag`, `preflight_only=true`, and
`npm_dist_tag=extended-stable`. A full SHA is a validation-only candidate
@@ -254,9 +258,10 @@ on pinned current `main` as the exact command and validation contract.
so trusted workflow code is pinned independently from the exact product
target. Save the successful run ID and its exact `run_attempt` from
`gh api repos/openclaw/openclaw/actions/runs/<run-id> --jq .run_attempt`.
4. If either candidate gate fails or another backport is needed, commit it to
the canonical branch, freeze its new SHA, and rerun the affected gates. Do
not create, delete, or move a final `vYYYY.M.P` tag for candidate validation.
4. If either candidate gate fails or another backport is needed, update the
canonical branch and its matching `CHANGELOG.md` section, freeze its new
SHA, and rerun the affected gates. Do not create, delete, or move a final
`vYYYY.M.P` tag for candidate validation.
5. Only after the candidate gates are green, re-resolve the canonical branch
tip and require it still equals the validated SHA. Create and push the
signed final `vYYYY.M.P` tag at that SHA. Never move or delete a final

25
docs/reference/RELEASING.md
View File

@@ -58,10 +58,13 @@ already contain a strictly later calendar month's final version below patch
month.
On the exact extended-stable branch, bump the root package to `YYYY.M.P`, run
`pnpm release:prep`, and verify every publishable plugin package has the
same version. Commit and push all generated changes, then freeze and record the
resulting full SHA. The workflows consume this prepared tree; they do not bump
or synchronize versions for you. Do not create the final tag for a candidate.
`pnpm release:prep`, and verify every publishable plugin package has the same
version. Generate a complete `## YYYY.M.P` section in `CHANGELOG.md` with the
required `### Highlights`, `### Changes`, and `### Fixes` headings, then commit
and push all generated changes. The npm preflight packages that exact tree and
rejects a missing or empty matching release section. Freeze and record the
resulting full SHA; the workflows do not bump versions, synchronize packages,
or create release notes for you. Do not create the final tag for a candidate.
Before running candidate gates, backport the complete Docker release-channel
change from current `main` as one tested unit. Its runtime files include
@@ -95,13 +98,13 @@ pins trusted workflow code while recording the exact product SHA and canonical
branch context. Its stable validation profile is separate from the npm
`extended-stable` dist-tag.
If either candidate gate fails or another backport is needed, update the branch,
freeze a new SHA, and rerun the affected candidate gates. Do not create, delete,
or move a final tag during candidate validation. Once both gates are green,
re-resolve the branch tip, require it still equals `RELEASE_SHA`, then create
and push signed `vYYYY.M.P` at that SHA. A post-tag source change requires a
new patch version and new candidate; final extended-stable tags are never moved
or deleted.
If either candidate gate fails or another backport is needed, update the branch
and its matching changelog section, freeze a new SHA, and rerun the affected
candidate gates. Do not create, delete, or move a final tag during candidate
validation. Once both gates are green, re-resolve the branch tip, require it
still equals `RELEASE_SHA`, then create and push signed `vYYYY.M.P` at that
SHA. A post-tag source change requires a new patch version and new candidate;
final extended-stable tags are never moved or deleted.
Pushing the tag starts `Docker Release`, which publishes version-specific
default, slim, browser, and architecture tags to both registries. It verifies their