docs/release-notes/1.0.0-rc.1.md is the user-facing release body (install
table, the Gatekeeper and SmartScreen notes, getting started, what is in
it, known limitations), with the exact rc.1 command sequence for James
in an HTML comment that GitHub does not render. release.mjs prints
--notes-file with that file when one exists for the version, else the
CHANGELOG section.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The orb (PR #165) publishes all four packages as rc when any of them is
a prerelease and as latest only when all are final. The readiness gate
gains a package-versions line that refuses a final CLI version while
client, core or conformance is still a prerelease; release.mjs derives
the dist-tag from all four. The runbook's version table, the rc-to-final
step and the publish step follow the rule, and its signing step now
uses sign-macos.sh and sign-windows.sh.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
scripts/readiness.mjs reports what a final release still lacks: parity
rows that are partial or todo in the CLI or TUI column (a blocked row
must cite a finding or issue), server findings without an issue link, a
missing CHANGELOG entry for the version, and qqq commands quoted in
README.md and TRY-IT.md that the program (createProgram from the built
CLI) does not have. release.mjs refuses a non-prerelease version until
the report is clean, prints it as information for a prerelease, and
--check prints only the report. Today: 122 CLI and 152 TUI rows open,
everything else clean.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A prerelease keeps rc and --prerelease; 1.0.0 prints --tag latest,
--latest, and the dist-tag commands that move latest while the orb
still publishes everything as rc. The printed packaging step names the
tap's formula path and the signing step.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
James's decision: one qqq binary per platform with the UI is the release
artifact. npm run binaries and release.mjs bundle the TUI unless
--cli-only. Both entries now start the built CLI (packages/cli/dist),
the module the TUI imports as @qrun-io/qqq-cli/program, so the CLI
program is in the bundle once (darwin-arm64: 100.8 -> 100.5 MB; the rest
of the 16 MB over the CLI-only build is React, OpenTUI and its native
library).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
release.mjs passes --with-tui to the binary build. docs/packaging
records the three ways tried to ship qqq ui (one binary with the UI, a
second qqq-ui binary, npm with Bun), the sizes, what was smoke-tested
and what was not, and recommends one qqq binary with the UI bundled.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
scripts/install.sh picks qqq-linux-<arch>-musl on Alpine, so a release
without them would leave those hosts with a 404.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The TUI is neither published nor bundled into the qqq binaries yet, but
it builds on the same kernel, so a release that breaks it should stop.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Clean tree, free tags, npm ci, the orb's generate-drift, build and test
steps, lint, npm pack dry runs and the binaries; then it prints the
signed tag, npm publish and gh release commands. It never tags,
pushes or publishes.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
james.maesandClaude Fable 5.1