@@ -301,7 +301,14 @@ node --import tsx scripts/openclaw-npm-postpublish-verify.ts <published-version>
301301 public release assets so the updater feed cannot lag the published binaries.
302302- Serialize stable appcast-producing runs across tags so two releases do not
303303 generate replacement `appcast.xml` files from the same stale seed.
304-- For stable releases, confirm the latest beta already passed the broader release workflows before cutting stable.
304+- For stable releases, rely primarily on the latest beta's broader release
305+ workflow confidence. When promoting the matching non-beta build to npm
306+`latest`, prefer a light time-bounded verification pass: published npm
307+ postpublish verify, Docker install/update smoke, macOS-only Parallels
308+ install/update smoke, and required QA signal. Do not rerun the full
309+ Docker/Parallels matrix unless the beta evidence is stale, the stable build
310+ differs materially from beta, or the operator explicitly asks for full
311+ retesting.
305312- If any required build, packaging step, or release workflow is red, do not say the release is ready.
306313307314## Use the right auth flow
@@ -475,10 +482,14 @@ node --import tsx scripts/openclaw-npm-postpublish-verify.ts <published-version>
475482 token from `.profile`.
47648325. If the operator requested beta only, stop after beta verification and the
477484 announcement.
478-26. If the stable release was published to `beta`, start the private
485+26. If the stable release was published to `beta`, use the light stable
486+ promotion roster when the matching beta already carried the full confidence
487+ pass: published npm postpublish verify, Docker install/update smoke,
488+ macOS-only Parallels install/update smoke, and required QA signal.
489+ Then start the private
479490`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
480- workflow after beta validation passes to promote that stable version from
481-`beta` to `latest`, then verify `latest` now points at that version.
491+ workflow to promote that stable version from `beta` to `latest`, then
492+ verify `latest` now points at that version.
48249327. If the stable release was published directly to `latest` and `beta` should
483494 follow it, start that same private dist-tag workflow to point `beta` at the
484495 stable version, then verify both `latest` and `beta` point at that version.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。