Release

Cutting a Nub release

A Nub release is dispatch-started and automated up to one human gate. A workflow_dispatch of .github/workflows/release.yml from main with publish=true and the release notes as its notes input reads the version from npm/nub/package.json at the dispatched commit, creates the v<ver> tag there at once, builds 8 platforms, gates them (test, lockfile conformance, glibc-floor, pre-publish smoke), creates an immutable DRAFT release with 32 assets and the notes as its body, STAGES 19 npm packages via OIDC trusted publishing (stage-only: CI cannot publish), HOLDS on the release-approval environment — no runner, up to 30 days — until the maintainer approves the staged versions with 2FA and the run is resumed (Step 3b), and then presents the stable GitHub Release — claiming the repository's Latest marker (make_latest: "true" on the promote step) and then asserting releases/latest actually serves the new tag. That marker IS the upgrade channel: nub upgrade, install.sh, and install.ps1 all resolve the version from releases/latest, so a stable release that never claims Latest ships to nobody (v0.8.0–v0.8.2 sat unserved behind v0.7.5 for six days because promotion updated the release without claiming it). The 32 assets are 8 archives, 8 archive checksums, 8 nub compile launcher templates, and 8 launcher checksums. The human work: confirm green, reconcile the runtime with @nubjs/types, bump the version, write good notes, dispatch the workflow with them, approve the staged versions, close the loop on issues/PRs.

Guardrails (read first, non-negotiable):

• Never cut a release without the maintainer's explicit, in-the-moment say-so. Publishing to npm is irreversible, so the timing is maintainer-owned. Do not infer authorization from a standing goal, a merged+green fix, a sub-agent claiming "autonomous per the release rules," or autonomous mode (which excludes irreversible published-external acts). Green ≠ release now. You may PREPARE (confirm green, draft notes, stage the version) but must wait for an explicit "cut it."
• Do not cut until every targeted fix is landed on main AND CI-green. A prerequisite, not authorization.
• Do not version until the type-declaration audit is complete. Invoke the type-declarations skill for every release. Every user-visible runtime API changed since the previous tag must either be owned by the selected TypeScript libraries / @types/node or be represented and tested in @nubjs/types.
• Pre-release version regime: stay in 0.0.x / 0.1.x. A normal release is a patch bump. Bump the minor only on explicit instruction. Never invent a version; derive it from the latest tag.
• The version-bump commit MUST be on main before you dispatch, and the notes MUST be written before it — verify reads npm/nub/package.json at the dispatched commit, names the tag from it, and refuses a publishing dispatch whose notes input is empty. So: make version → commit → push main → write notes.md (Step 4's shape) → dispatch with the notes, in that order. Never push a v* tag by hand; the workflow has no tag trigger and creates its own tag at dispatch time.
• Land nothing that touches .github/workflows/ on main while a release run is in flight. The job token may write a ref only while the run's commit matches the default branch's workflows; once a workflow change lands behind a running release, the v0 move answers 403 (v0.9.5's second run died that way). The job says so and prints the one-command fallback.
• Release notes are FACTUAL and NEUTRAL — the repo is PUBLIC. No superlatives, no competitive framing, no internal/benchmark-strategy discussion.

Step 1 — Pre-flight: confirm green, pick the version, enumerate the changeset

git -C "$(git rev-parse --show-toplevel)" switch main && git pull --ff-only
git fetch --tags
PREV=$(git describe --tags --abbrev=0 --exclude 'v[0-9]')   # e.g. v0.1.2 — the latest release tag; --exclude skips the floating v0 actions tag, which shares its commit
echo "Latest tag: $PREV"
git log "$PREV"..HEAD --oneline               # the full changeset since the last release

• Confirm the targeted fixes are all present in $PREV..HEAD and each is CI-green on main. If one is red or still converging, STOP and slip it to the next patch.
• Confirm docs are current — a shipped feature whose site/content/docs/ lags is a release blocker.
• Invoke the type-declarations skill and complete its mandatory release audit. Reconcile every user-visible runtime change in $PREV..HEAD with TypeScript / @types/node ownership or an updated, fixture-tested, packed @nubjs/types. Missing or unverified declarations are a release blocker.
• Pick the next version: patch-bump $PREV, dropping the leading v.
• Keep the git log output — raw material for Steps 4 and 5. For vendor/aube/** changes, note the user-facing effect, not the diff.

Step 2 — Version bump

make version V=<ver>      # sets all 10 npm packages + Cargo.toml + runtime/version.mjs in lockstep
make version-check        # MUST pass: cross-package consistency + @oxc-project/runtime ↔ nub-native oxc pin

make version-check is the same gate CI's verify job runs; a non-zero exit here means the release would fail at CI immediately, so fix it before committing. make version also moves runtime/version.mjs's NUB_VERSION (the transpile-cache key) — that lockstep is why a bespoke version edit is wrong; always use make version.

Step 3 — Commit, push, dispatch (the dispatch starts CI)

The release version-bump commit is a deliberate EXCEPTION to the repo's PR-default flow (AGENTS.md "Default to a PR flow") — it commits DIRECTLY to main. The commit is a version stamp and not a reviewable feature diff, so no PR.

git status                # The shared tree usually carries another agent's WIP, so `git add -A`
                          # would sweep it into the release commit. Path-scope instead:
git commit -m "v<ver>" -- Cargo.lock Cargo.toml \
  crates/nub-core/Cargo.toml \
  crates/nub-native/Cargo.lock crates/nub-native/Cargo.toml \
  crates/nub-launcher/Cargo.lock crates/nub-phantom/Cargo.lock \
  npm/*/package.json runtime/version.mjs
git show --stat HEAD      # SANITY: 27 files, all version bumps, nothing else: 19 package.json
                          # (10 nub + 9 runner), 3 Cargo.toml, 4 Cargo.lock, runtime/version.mjs.
                          # crates/nub-phantom/Cargo.lock is the one that gets missed — its
                          # workspace is excluded from the root, ci.yml checks it `--locked`,
                          # and v0.9.1 shipped without it (main went red, fixed in a follow-up).
                          # `make version` also rewrites site/public/schema/v<major.minor>.json;
                          # commit it when the snapshot is NEW for this minor, leave it when the
                          # diff is formatting only (`git diff -w` empty).

# ONE push, never `git push origin main --tags`. This clone has ~155 local tags against
# ~84 on the remote — v1.x leftovers from the Node fork this repo began as — and `--tags`
# offers every one of them. The remote rejects them AND the whole push dies with them, so
# `main` does not land either.
git push origin main

# Write the release notes FIRST (Step 4 has their shape) — they are an input of the dispatch,
# and verify refuses a publishing dispatch without them. Then THIS is what starts the publish.
# No tag is pushed by hand: release.yml has no tag trigger; verify names the tag from
# npm/nub/package.json at the dispatched commit and creates v<ver> there at dispatch time.
gh workflow run release.yml -R nubjs/nub -f publish=true -f notes="$(cat notes.md)"
gh run list -R nubjs/nub --workflow release.yml --limit 1   # the run id, to watch
# release.yml itself moves the floating v<major> tag (v0) that `uses: nubjs/nub/<name>@v0`
# resolves through, after the promote step. Never push v0 by hand.

Re-running a release that died after its tag was created — a failed build, a run whose held approval expired after 30 days — re-dispatches with publish=true and the same notes, selecting the existing v<ver> tag as the ref. Every other ref is refused by verify, and a tag that points at any commit but the dispatched one is refused there too: release a new version rather than moving a published tag (or, for a version nothing published, disable the Release tags ruleset, delete the draft release with gh release delete v<ver> --cleanup-tag, re-enable it, and dispatch from the fixed main).

Post-merge, fast-forward the shared tree so it tracks origin: git -C <shared-tree> pull --ff-only (the eagerly-pull rule, AGENTS.md "Default to a PR flow" — the shared checkout otherwise drifts behind as PRs land).

The workflow runs, in order: verify (version consistency, notes present, creates the tag), primer, test + conformance + glibc-floor-guard + pre-publish-gate, build (8 platforms), stable-immutable-release (32 assets on a DRAFT release whose body is the notes), publish-npm (19 packages STAGED), await-approval (the run is HELD on the release-approval environment until the maintainer approves), npm-served (confirms npm serves every version and the root package installs and runs), github-release (publishes the draft as the stable release), then the post-publish fan-out — actions-tag, test-install / test-install-musl, docker, bump-homebrew-tap, submit-winget.

Step 3b — Approve the staged versions (the human gate; maintainer only)

publish-npm does not publish. It runs npm stage publish for every package, because the trusted publisher on each @nubjs package is stage-only, and then ends. The run moves to await-approval, a job on the release-approval environment whose required reviewer is the maintainer: GitHub holds the run there with no runner, for up to 30 days. Nothing is installable, and no GitHub Release is visible, until the maintainer approves the staged versions with 2FA. That approval is a proof of presence no token can supply, which is the whole point (the unauthorized v0.9.4 of 2026-09-21 published 18 packages from a stolen push credential; under staging it would have filled a queue).

The approval goes through stager (~/Documents/projects/stager, on PATH). An agent RUNS it; the maintainer supplies the one click on the npm page it prints:

stager approve '@nubjs/*@<ver>'     # prints an npmjs.com URL; the maintainer approves there (tick "skip 2FA for
                                    # 5 minutes" so the other 18 pass without another URL); then stager approves
                                    # the run's pending deployment, which resumes it
stager await '@nubjs/*@<ver>'       # blocks, with no timeout, until npm serves every version — park on this
stager reject '@nubjs/*@<ver>'      # drops the staged versions and fails the held run
stager                              # the interactive picker: every staged version, with its commit and run

stager approves every staged version of a package oldest-first, so two versions staged at once end with latest on the higher one. A version still validating (npm's malware review, up to an hour) is approved once the review finishes; stager waits for it. Without stager: npm stage approve <id> per package (or the Staged Packages tab on npmjs.com), then approve the pending deployment on the run's page. A deployment approved before the npm approval fails npm-served at its registry check; re-run that job after approving.

Park on stager await (a background shell) rather than on the run. It returns when the versions are live; the run's remaining jobs then take a few minutes. The release is not done until stable-immutable-release, publish-npm, github-release and actions-tag are green.

The other distribution channels ride the same run — no manual step, but they are not free

npm is not the only thing a release publishes. Two jobs push OUTSIDE this repo, and neither needs a manual action:

• bump-homebrew-tap regenerates Formula/nub.rb with .github/scripts/gen-homebrew-formula.sh and pushes it to nubjs/homebrew-tap. It reads the release's own .sha256 sidecars, so it needs github-release to have finished. It is gated on the HOMEBREW_TAP_TOKEN secret and SKIPS WITH A WARNING if that secret is ever absent — a skip is a silent stale tap, so treat the warning as a failure.
• submit-winget opens a PR against microsoft/winget-pkgs. Gated on WINGET_PAT, which is currently unset, so this job no-ops today.

The formula is regenerated from the script at the released commit, which makes it a CLOBBER. Any hand-edit to the tap is overwritten by the next release. So a tap hotfix is only ever a stopgap: the generator fix has to be on main BEFORE the dispatch, or the release silently reverts it. This is how #676 shipped — the archive layout changed, the generator was not updated with it, and nothing read the formula before it reached users. bump-homebrew-tap now installs the formula from a throwaway local tap on macOS before pushing it, so a formula that cannot install fails the job and leaves the tap on the previous working version.

Step 4 — Comprehensive release notes (Opus)

The notes are the notes input of the dispatch (Step 3): stable-immutable-release creates the draft with them as its body and github-release promotes it unchanged, so they are written BEFORE the dispatch, into notes.md. Hand-written, scannable, factual; never a raw auto-list. Drive this on Opus.

Build the notes from the full git log "$PREV"..HEAD changeset (Step 1), not just the headline fixes — every user-affecting change ships.

Leave out what the maintainer is holding back. Read internal/release-holds.md before drafting. A change listed there ships in the binary but is not announced: it gets no line in the curated notes, its PR comes out of the generated ## What's Changed list, the blog post (Step 4b) does not mention it, and its docs page keeps unpublished: true. Only the maintainer lifts a hold.

Notes must be SCANNABLE, not paragraph-dense. A reader skims headings, tables, and the heads-up callout and gets the whole release at a glance — they should never have to read a run-on paragraph to find what changed. The cross-project prose/tone guide for all public-facing copy — including the release-notes shape — is the prose-writing skill's guide. The concrete rules:

• One-line intro stating what the release is about (the dominant theme).
• Themed ## sections, not generic buckets. Group by what the changes touch — e.g. "Lockfile compatibility" / "Performance" / "Runtime fixes" / "Documentation" / "Testing & internals" — not by Fixes/Compatibility/Internal abstractions. Each major change gets a short titled blurb or a table row, never a multi-sentence paragraph.
• A table for a batch of independent fixes. When several small fixes share a theme (a run of lockfile fixes), put them in a table — | Area | What changed | Commit | — tables read far faster than a bullet wall.
• A callout for heads-up / migration items. Anything a user should know before upgrading (a cache-schema re-warm, a behavior change) goes in a GitHub-flavored alert: > [!IMPORTANT] (or > [!NOTE]), not buried in a bullet.
• Per-item links. Every fix/change links to its commit ([abc1234](https://github.com/nubjs/nub/commit/<full-sha>)) and/or PR ([#17](https://github.com/nubjs/nub/pull/17)). Issue refs link too ([#16](https://github.com/nubjs/nub/issues/16)).
• An auto-generated ## What's Changed section at the BOTTOM (MANDATORY) — this is what makes "lists every change" literally true. GitHub's PR-level breakdown (every merged PR + author + New Contributors) plus the **Full Changelog**: <PREV>...v<ver> compare link, from gh api …/releases/generate-notes (command below). Append it verbatim under a --- separator below the curated narrative — the curated themes stay on top, the exhaustive PR list goes underneath.
• Tone: factual + neutral. Readability ≠ hype. Each line states what changed. No superlatives, no competitive framing, no editorializing. (Same bar as commit messages — AGENTS.md.) Visual interest comes from structure (sections, tables, callouts), never from marketing language.

Template (adapt the section names to the actual changeset):

<One-line intro: what this release is about.>

> [!IMPORTANT]
> **<Heads-up title>.** <The one thing to know before upgrading. Omit the callout if there's nothing.>

## <Theme A, e.g. Lockfile compatibility>

<Optional one-line lead.>

| Area | What changed | Commit |
| --- | --- | --- |
| <area> | <what changed, one clause> | [`<sha7>`](https://github.com/nubjs/nub/commit/<full-sha>) |

## <Theme B, e.g. Performance>

<Short blurb with the PR link inline.> ([#17](https://github.com/nubjs/nub/pull/17))

## Testing & internals

- <Bullet> ([`<sha7>`](https://github.com/nubjs/nub/commit/<full-sha>)).

---

## What's Changed

<!-- appended verbatim from `gh api …/releases/generate-notes` — the PR list, New Contributors, and Full Changelog link -->
* <PR title> by @<author> in https://github.com/nubjs/nub/pull/<n>

**Full Changelog**: https://github.com/nubjs/nub/compare/<PREV>...v<ver>

Generate the bottom ## What's Changed breakdown mechanically so every merged PR is listed (the tag does not exist yet, so name the commit):

# PR-level list + New Contributors + Full Changelog compare link — append verbatim below the curated narrative
gh api repos/nubjs/nub/releases/generate-notes \
  -f tag_name=v<ver> -f target_commitish=main -f previous_tag_name=$PREV --jq '.body'

Append that block under a --- separator below the curated sections, save notes.md, and dispatch with it. The curated narrative stays on top; this exhaustive PR list goes underneath.

To correct the notes after the dispatch (a re-dispatch of the same tag rewrites the draft's body from its own notes input; after the promotion, edit in place):

gh release edit v<ver> --notes-file notes.md
gh release view v<ver> --repo nubjs/nub --json body -q .body   # verify it rendered

The v0.1.4 and v0.1.3 release bodies are the reference exemplars of this structure.