v0.24.3-beta shipped without a release. The workflow compared the version in
HEAD against HEAD~1, so a bump pushed together with any follow-up commit —
here a docs commit — was no longer the tip and nothing looked changed.
It now asks whether a tag for the current version already exists. That does
not care how commits are batched, is safe to re-run, and makes the job
idempotent rather than dependent on push shape. The paths filter is dropped
for the same reason: the tag check is the real guard.
Release notes are taken from the commit that last touched the version rather
than the tip, since a bump is often followed by docs or CI commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The release notes were passed through a step output and interpolated straight
into the gh command. Commit messages here routinely contain backticks, so the
shell evaluated them as command substitution — which failed the first release
outright, and would let a commit message run arbitrary code in CI.
Notes are written to a file and passed with --notes-file; nothing from the
commit reaches a shell as code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The dashboard sends people to the releases page to see what changed. That page
held a single entry from five months earlier while the product shipped several
times a day, which tells a visitor the project is abandoned — raised on #119,
and the more useful half of that thread.
A release is now cut whenever the shipped version changes, tagged to match the
container image so the thing you are running and the notes you are reading carry
the same number. Notes are the commit body rather than a generated list of
subjects, because the commit messages here already explain what changed and why.
Betas are marked pre-release so nobody is pointed at one by accident.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2GT-RichandClaude Opus 5