docs: remove alpha release references

This commit is contained in:
Peter Steinberger
2026-05-02 23:40:14 +01:00
parent dfce72d136
commit 816f3f11a1
3 changed files with 9 additions and 26 deletions

View File

@@ -51,7 +51,6 @@ Docs: https://docs.openclaw.ai
### Highlights
- Alpha prerelease support adds the `vYYYY.M.D-alpha.N` tag shape, npm `alpha` dist-tag, release workflow inputs, package acceptance, Telegram package checks, and upgrade-survivor validation paths.
- External plugin installation now covers diagnostics, onboarding, doctor repair, channel setup, install/update records, and artifact metadata while keeping bare package installs on npm for the first cutover. Thanks @vincentkoc.
- Gateway startup, session listing, task maintenance, prompt prep, plugin loading, and filesystem hot paths get targeted cache and fanout reductions for large or plugin-heavy installs.
- Control UI and WebChat reliability improves across Sessions, Cron, long-running Gateway WebSockets, grouped-message width, slash-command feedback, iOS PWA bounds, selection contrast, and Talk diagnostics.
@@ -59,7 +58,6 @@ Docs: https://docs.openclaw.ai
### Changes
- Release: add first-class alpha prerelease support across version parsing, release workflows, package specs, published-package validation, plugin publish planning, and release docs.
- Gateway/startup: skip plugin-backed auth-profile overlays during startup secrets preflight, reducing gateway readiness latency while keeping reload and OAuth recovery paths overlay-capable. (#68327) Thanks @JIRBOY.
- Plugins/ClawHub: make diagnostics, onboarding, doctor repair, and channel setup carry ClawPack metadata through install records while keeping explicit `clawhub:` installs on ClawHub and bare package installs on npm for the launch cutover. Thanks @vincentkoc.
- Plugins/runtime: scope broad runtime preloads to the effective plugin ids derived from config, startup planning, configured channels, slots, and auto-enable rules instead of importing every discoverable plugin.

View File

@@ -239,7 +239,7 @@ Use `Package Acceptance` when the question is "does this installable OpenClaw pa
### Candidate sources
- `source=npm` accepts only `openclaw@alpha`, `openclaw@beta`, `openclaw@latest`, or an exact OpenClaw release version such as `openclaw@2026.4.27-beta.2`. Use this for published prerelease/stable acceptance.
- `source=npm` accepts only `openclaw@beta`, `openclaw@latest`, or an exact OpenClaw release version such as `openclaw@2026.4.27-beta.2`. Use this for published prerelease/stable acceptance.
- `source=ref` packs a trusted `package_ref` branch, tag, or full commit SHA. The resolver fetches OpenClaw branches/tags, verifies the selected commit is reachable from repository branch history or a release tag, installs deps in a detached worktree, and packs it with `scripts/package-openclaw-for-docker.mjs`.
- `source=url` downloads an HTTPS `.tgz`; `package_sha256` is required.
- `source=artifact` downloads one `.tgz` from `artifact_run_id` and `artifact_name`; `package_sha256` is optional but should be supplied for externally shared artifacts.

View File

@@ -7,10 +7,9 @@ read_when:
- Looking for version naming and cadence
---
OpenClaw has four public release lanes:
OpenClaw has three public release lanes:
- stable: tagged releases that publish to npm `beta` by default, or to npm `latest` when explicitly requested
- alpha: prerelease tags that publish to npm `alpha`
- beta: prerelease tags that publish to npm `beta`
- dev: the moving head of `main`
@@ -20,13 +19,10 @@ OpenClaw has four public release lanes:
- Git tag: `vYYYY.M.D`
- Stable correction release version: `YYYY.M.D-N`
- Git tag: `vYYYY.M.D-N`
- Alpha prerelease version: `YYYY.M.D-alpha.N`
- Git tag: `vYYYY.M.D-alpha.N`
- Beta prerelease version: `YYYY.M.D-beta.N`
- Git tag: `vYYYY.M.D-beta.N`
- Do not zero-pad month or day
- `latest` means the current promoted stable npm release
- `alpha` means the current alpha install target
- `beta` means the current beta install target
- Stable and stable correction releases publish to npm `beta` by default; release operators can target `latest` explicitly, or promote a vetted beta build later
- Every stable OpenClaw release ships the npm package and macOS app together;
@@ -79,15 +75,15 @@ the maintainer-only release runbook.
file, lane, workflow job, package profile, provider, or model allowlist that
proves the fix. Rerun the full umbrella only when the changed surface makes
prior evidence stale.
9. For alpha or beta, tag `vYYYY.M.D-alpha.N` or `vYYYY.M.D-beta.N`, then run `OpenClaw Release Publish` from
9. For beta, tag `vYYYY.M.D-beta.N`, then run `OpenClaw Release Publish` from
the matching `release/YYYY.M.D` branch. It verifies `pnpm plugins:sync:check`,
publishes all publishable plugin packages to npm first, publishes the same
set to ClawHub second, and then promotes the prepared OpenClaw npm preflight
artifact with the matching dist-tag. After publish, run post-publish package
acceptance against the published `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`,
`openclaw@YYYY.M.D-beta.N`, or `openclaw@beta` package. If a pushed or
published prerelease needs a fix, cut the next matching prerelease number;
do not delete or rewrite the old prerelease.
acceptance against the published `openclaw@YYYY.M.D-beta.N` or
`openclaw@beta` package. If a pushed or published prerelease needs a fix,
cut the next matching prerelease number; do not delete or rewrite the old
prerelease.
10. For stable, continue only after the vetted beta or release candidate has the
required validation evidence. Stable npm publish also goes through
`OpenClaw Release Publish`, reusing the successful preflight artifact via
@@ -132,7 +128,7 @@ the maintainer-only release runbook.
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
- Run the manual `Package Acceptance` workflow when you want side-channel proof
for a package candidate while release work continues. Use `source=npm` for
`openclaw@alpha`, `openclaw@beta`, `openclaw@latest`, or an exact release version; `source=ref`
`openclaw@beta`, `openclaw@latest`, or an exact release version; `source=ref`
to pack a trusted `package_ref` branch/tag/SHA with the current
`workflow_ref` harness; `source=url` for an HTTPS tarball with a required
SHA-256; or `source=artifact` for a tarball uploaded by another GitHub
@@ -559,16 +555,6 @@ gh workflow run openclaw-release-publish.yml \
-f npm_dist_tag=beta
```
Alpha publish example:
```bash
gh workflow run openclaw-release-publish.yml \
--ref release/YYYY.M.D \
-f tag=vYYYY.M.D-alpha.N \
-f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
-f npm_dist_tag=alpha
```
Stable publish to the default beta dist-tag:
```bash
@@ -600,7 +586,7 @@ OpenClaw package must not be published.
`OpenClaw NPM Release` accepts these operator-controlled inputs:
- `tag`: required release tag such as `v2026.4.2`, `v2026.4.2-1`, or
`v2026.4.2-alpha.1` or `v2026.4.2-beta.1`; when `preflight_only=true`, it may also be the current
`v2026.4.2-beta.1`; when `preflight_only=true`, it may also be the current
full 40-character workflow-branch commit SHA for validation-only preflight
- `preflight_only`: `true` for validation/build/package only, `false` for the
real publish path
@@ -630,7 +616,6 @@ OpenClaw package must not be published.
Rules:
- Stable and correction tags may publish to either `beta` or `latest`
- Alpha prerelease tags may publish only to `alpha`
- Beta prerelease tags may publish only to `beta`
- For `OpenClaw NPM Release`, full commit SHA input is allowed only when
`preflight_only=true`