Repository navigation
chore: publish betas on the beta npm tag #329
Description
Why
Older installations follow latest and next, so betas need their own tag (master plan Decision 1).
In scope
Change the release workflow to publish 4.0.0-beta.N on beta.
Out of scope
Other release changes.
Acceptance criteria
- A dry run publishes to beta only
- latest and next are untouched
Dependencies
Blocked by: None
Blocks: #385
Plan
- Release:
4.0.0-beta.1 - Size:
size:S· Workstream:ws:release - Epic: feat: project-scope P0, removals and the enforcement baseline (epic) #295
- Card:
P0-09in the card inventory - Sources: Master plan (docs(plans): v4 GA master plan, supersession ledger and v5 registers #290) Decision 1
Verification
actionlint- Release workflow dry run
Activity
test(release): run the dist-tag CLI test with a sandboxed env
test(release): resolve the script path portably for Windows
ci(release): publish betas on the beta npm tag (#440)
chore(upstream): record AQE and Brain verification, sunset the Codex …
pacphi commentedon Oct 13, 2026
Acceptance sweep 2026-10-13: both boxes stay open on purpose. The only dry run (run 37151216803, 2026-10-03) ran at 4.0.0-alpha.61 and printed
publishing 4.0.0-alpha.61 on dist-tag 'next'; no beta version has been dry-run and npm has nobetadist-tag. The mapping script is unit-tested (4.0.0-beta.1 -> beta). Follow-up, agreed by the maintainer: run the workflow_dispatch dry run on a beta version (before or as part of REL-B1, #385), confirm it printsdist-tag 'beta'and leaveslatestandnextuntouched, then tick both boxes.