doc/RELEASING.md
Maintainer runbook for shipping Paperclip across npm, GitHub, and the website-facing changelog surface.
The release model is now commit-driven:
master publishes a canary automatically.releases/vYYYY.MDD.P.md. They are
drafted automatically when a beta is published (as
releases/beta/v<beta-version>.md on master), edited during the
soak, and moved to the versioned name after the stable ships.The user-facing guide to the channels is CHANNELS.md.
Paperclip uses calendar versions that still fit semver syntax:
YYYY.MDD.PYYYY.MDD.P-canary.NYYYY.MDD.P-nightly.NYYYY.MDD.P-beta.NExamples:
2026.318.02026.318.12026.318.1 line: 2026.318.1-canary.32026.318.1-nightly.02026.318.1-beta.0A promotion republishes the exact source commit of the previous lane's build (canary → nightly → beta); the version dates the promotion, not the source build.
Important constraints:
MDD, where M is the UTC month and DD is the zero-padded UTC day2026.303.0 for March 3, not 2026.33.02026.0318.02026.3.18.12026.318.0-canary.1Every stable release has four separate surfaces:
paperclipai and public workspace packages are publishedA stable release is done only when all four surfaces are handled.
Canaries, nightlies, and betas only cover the first two surfaces plus an internal traceability tag.
mastercanary/v* tag), and only after the release smoke suite passes
against that exact published canarynightly/v* tag), behind the npm-beta approval gate, and the
published beta is re-smokedreleases/vYYYY.MDD.P.md in the end state: a
promoted beta's notes are drafted and edited at
releases/beta/v<beta-version>.md on master during the soak (the
promoted commit cannot carry a file named for a promotion date that was
unknown when it was created), and a post-stable canonicalization PR
moves them to the versioned name:latest moves only on stable releases; master builds publish
:canary, nightly builds :nightly, and beta builds :betaEvery push to master runs the canary path inside .github/workflows/release.yml.
It:
canarypaperclipai package last, so paperclipai@canary does not advance before the full package set existscanary resolves to the just-published version and that published internal dependencies exist on npmpaperclipai@canary into a clean temporary prefix as the final npm gatelatest pointing at a canary; use --allow-canary-latest only when that state is intentionalcanary/vYYYY.MDD.P-canary.NUsers install canaries with:
npx paperclipai@canary onboard
# or
npx paperclipai@canary onboard --data-dir "$(mktemp -d /tmp/paperclip-canary.XXXXXX)"
A scheduled job in .github/workflows/release.yml
runs once a night at 09:00 UTC.
It:
master that carries a canary/v* tag (the
tag is pushed only after a successful canary publish, so it is the
green-publish signal)release-smoke.yml)
against that exact published canary version — red smoke means no nightly
tonightYYYY.MDD.P-nightly.N under the npm
dist-tag nightly (the commit was already verified by its canary run, so
verification is not repeated)nightly/vYYYY.MDD.P-nightly.Ndocker.yml at that tag to
publish the :nightly imagesTo force a nightly outside the schedule (recovery, or promoting a specific
canary), dispatch release.yml with channel: nightly. Leave
source_version empty for automatic selection, or set it to an exact
canary version. dry_run: true previews the publish and skips smoke, the tag
push, and the Docker dispatch.
Users install nightlies with:
npx paperclipai@nightly onboard
Betas are manual promotions. Dispatch
release.yml with channel: beta.
source_version empty to promote the newest nightly, or set it to an
exact nightly version such as 2026.807.0-nightly.0npm-beta environment — its
required reviewers are the promotion gateYYYY.MDD.P-beta.N under the npm
dist-tag beta, tagged beta/vYYYY.MDD.P-beta.N, and docker.yml is
dispatched at that tag to publish the :beta imagesdraft_stable_notes job also generates the eventual stable's notes
skeleton — releases/beta/v<beta-version>.md, grouped from
git log <last-stable-tag>..<source-commit> — and force-pushes it to the
machine-owned release-notes/v<beta-version> branch. Open the PR from
the job-summary link (a human opens it so CI runs) and edit the notes
during the soak; the stable promotion reads the merged file from
masterdry_run: true previews the publish and skips the tag push, Docker
dispatch, and post-publish smokeUsers install betas with:
npx paperclipai@beta onboard
When one or two targeted fixes are needed before beta and waiting for the
next nightly (or absorbing a whole day of master) is wrong, build the beta
from a short-lived candidate branch:
candidate/beta-<target> from the chosen nightly's source commit
(for example candidate/beta-2026.811.0)release.yml with channel: beta and candidate_branch: candidate/beta-<target>master normally and delete the
candidate branchUse this sparingly: the happy path is promoting a nightly. A candidate build
has its own -beta.N identity and is never pretended to be the nightly it
was cut from.
Use .github/workflows/release.yml from the Actions tab with the manual workflow_dispatch inputs.
Inputs:
channel
stable (the default) for a stable release; beta and nightly run
those lanes instead (see above)source_ref
stable_date
YYYY-MM-DD2026-03-18, not a version like 2026.318.0skip_soak_justification
dry_run
The stable preflight enforces the beta soak: the source commit must carry a
beta/v* tag whose npm publish time is at least 3 days old. If it is not,
the run fails unless skip_soak_justification is provided; the justification
is echoed into the job summary. Dry runs report soak state without blocking.
For a cherry-picked stable (the release fix path), cut
candidate/release-<target> from the chosen beta's source commit,
cherry-pick the required fixes, push the branch, and use it as
source_ref. The candidate head carries no beta/v* tag, so the soak gate
requires skip_soak_justification — that is deliberate: the exact bits were
not soaked, and the justification is the recorded trade-off. Reconcile the
fixes back to master and delete the branch after shipping.
Before running stable:
source_ref)./scripts/release.sh stable --date "$(date +%F)" --print-versionrelease-notes/v<beta-version>, adding
releases/beta/v<beta-version>.md) is merged on master — or, for
candidate builds, that the candidate branch itself carries
releases/vYYYY.MDD.P.mdExample:
source_ref: masterstable_date: 2026-03-182026.318.0The workflow:
releases/vYYYY.MDD.P.md at
the source commit (the candidate fix path) takes precedence, otherwise
releases/beta/v<beta-version>.md on master (a promoted beta). When
neither exists the run fails before the npm-stable approval gate with
the missing path namedYYYY.MDD.P under npm dist-tag latestvYYYY.MDD.Pdocker.yml at that tag to
publish :latest and the versioned stable imagesrelease-notes/v<version>-canonicalize
branch that git mvs them to releases/vYYYY.MDD.P.md — open and merge
its PR to restore the canonical layoutdocker.yml publishes both the self-hosted
image and the -cloud variant with the same lane mapping:
| Build ref | Tags |
|---|---|
master push | :canary, :sha-<short> |
nightly/v* tag | :nightly, :sha-<short> |
beta/v* tag | :beta, :sha-<short> |
v* tag (stable) | :latest, :YYYY.MDD.P, :YYYY.MDD, :sha-<short> |
Lane tags are pushed by release workflows using GITHUB_TOKEN, and GitHub
suppresses push-triggered workflow runs for those pushes. The release jobs
therefore dispatch docker.yml explicitly at the new tag ref; the tag
mapping keys off github.ref either way.
./scripts/release.sh canary --dry-run
Requires HEAD to be a commit that already shipped a canary (it must carry a
canary/v* tag):
./scripts/release.sh nightly --dry-run
Requires HEAD to be a commit that already shipped a nightly (it must carry a
nightly/v* tag):
./scripts/release.sh beta --dry-run
./scripts/release.sh stable --dry-run
This is mainly for emergency/manual use. The normal path is the GitHub workflow.
./scripts/release.sh stable
git push public-gh refs/tags/vYYYY.MDD.P
PUBLISH_REMOTE=public-gh ./scripts/create-github-release.sh YYYY.MDD.P
Stable changelog files live at:
releases/vYYYY.MDD.P.mdCanaries do not get changelog files.
The draft_stable_notes job seeds a deterministic skeleton (grouped
commit subjects) on the release-notes/v<beta-version> branch at beta
publish; the flows below turn that skeleton into narrative release notes
during the soak. Run them against the draft branch's
releases/beta/v<beta-version>.md and push to the notes PR.
Recommended local generation flow:
VERSION="$(./scripts/release.sh stable --date 2026-03-18 --print-version)"
claude --print --output-format stream-json --verbose --dangerously-skip-permissions --model claude-opus-4-6 "Use the release-changelog skill to draft or update releases/v${VERSION}.md for Paperclip. Read doc/RELEASING.md and .agents/skills/release-changelog/SKILL.md, then generate the stable changelog for v${VERSION} from commits since the last stable tag. Do not create a canary changelog."
The repo intentionally does not run this through GitHub Actions because:
For a canary:
PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh
For the current stable:
PAPERCLIPAI_VERSION=latest ./scripts/docker-onboard-smoke.sh
Useful isolated variants:
HOST_PORT=3232 DATA_DIR=./data/release-smoke-canary PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh
HOST_PORT=3233 DATA_DIR=./data/release-smoke-stable PAPERCLIPAI_VERSION=latest ./scripts/docker-onboard-smoke.sh
Automated browser smoke is also available:
gh workflow run release-smoke.yml -f paperclip_version=canary
gh workflow run release-smoke.yml -f paperclip_version=nightly
gh workflow run release-smoke.yml -f paperclip_version=beta
gh workflow run release-smoke.yml -f paperclip_version=latest
The nightly lane runs this same suite automatically against its candidate before publishing, and the beta lane runs it against the published beta as post-publish verification.
Minimum checks:
npx paperclipai@canary onboard installsRollback does not unpublish versions.
It only moves the latest dist-tag back to a previous stable:
./scripts/rollback-latest.sh 2026.318.0 --dry-run
./scripts/rollback-latest.sh 2026.318.0
Then fix forward with a new stable patch slot or release date.
Do not run stable.
Instead:
masterA skipped nightly is working as designed — the job summary names the reason (no new green candidate, candidate already shipped, or red smoke). Nothing was published, so there is nothing to clean up.
To recover after fixing the cause, either wait for the next scheduled run or
force one: dispatch release.yml with channel: nightly (optionally pinning
source_version to a specific canary).
If the nightly published to npm but the tag push or Docker dispatch failed,
push the nightly/v* tag manually and run docker.yml at that tag.
GITHUB_TOKEN may not create refs that point at commits which modify workflow
files when the run was started by dispatch or schedule (push-triggered runs
are exempt, which is why canary tags on the same commit succeed). The npm
publish is already complete and correct when this happens. The failed job's
summary contains the exact recovery commands: create and push the tag with
maintainer credentials, then dispatch docker.yml at the tag (and for
stable, run create-github-release.sh). This only occurs when a
release-infrastructure commit itself becomes a promotion source.
Do not promote it to stable. Fix forward: land the fix on master, let it
ship through canary and nightly, and promote a new beta. The soak clock
starts over for the new beta.
If the published beta is actively harmful to beta users, move the beta
dist-tag back to the previous beta version with npm dist-tag add per
package, and re-point the :beta Docker tags at the previous beta's images.
This is a partial release. npm is already live.
Do this immediately:
PUBLISH_REMOTE=public-gh ./scripts/create-github-release.sh YYYY.MDD.Preleases/vYYYY.MDD.P.mdDo not republish the same version.
latest is broken after stable publishRoll back the dist-tag:
./scripts/rollback-latest.sh YYYY.MDD.P
Then fix forward with a new stable release.