release

Release Workflow

Steps

1. Sync the release branch with main: The release worktree's branch lags main between releases — it's only reset to main after a release lands. Cutting from a stale branch silently drops everything merged since. Fast-forward to the tip of main before anything else:

   git fetch origin
   git merge --ff-only origin/main
   

   --ff-only advances the branch when it's a strict ancestor of origin/main and fails (rather than creating a merge commit or discarding work) if it has diverged — reconcile manually before continuing. This is the release-branch equivalent of wt up, spelled out because the up alias rebases each branch onto its own upstream (origin/release), not main. Note the resulting commit SHA: this is the tip the changelog covers, and step 12 checks the changelog against everything that reaches main before the tag.
2. Run tests: Two gates — the local suite and the full cross-platform suite.
   • Local: cargo run -- hook pre-merge --yes.
   • Cross-platform: dispatch the nightly workflow on the cut-from tip and wait for it to go green. This is where a release gets its full linux/macos/windows validation: the PR path (ci.yaml) is moving to cargo-affected selection and will stop running the full test matrix, while nightly hosts full-tests (the full 3-OS suite) alongside feature-powerset, release-target, nix-flake, and minimal-versions. Benchmarks aren't part of nightly — they run in their own benchmarks.yaml and gate nothing.

     gh workflow run nightly.yaml --ref main
     # Registration lags the dispatch, and a prior release may have left a
     # stale completed workflow_dispatch run — filter to the in-flight one.
     sleep 5
     RUN=$(gh run list --workflow=nightly.yaml --event=workflow_dispatch --branch=main --limit 5 --json databaseId,status --jq 'map(select(.status != "completed")) | .[0].databaseId')
     

     Launch a ci-reporter to monitor $RUN to completion (avoid gh run watch — it can hang). Fix any failure before continuing.
3. Check current version: Read version in Cargo.toml
4. Review commits: Check commits since last release to understand scope of changes. Audit the cumulative diff for the data-loss surface (see Data-Loss Surface Review) and documentation (see Documentation Review).
5. Check library API compatibility (advisory): Run `cargo semver-checks