Release

Release MQTT Viewer

Drives the runbook in docs/RELEASING.md. One release is one annotated GitHub release on main; publishing it fires three workflows (mac / windows / linux) that build, sign, upload assets, and register the version with the portal. Nothing reaches users until the released toggle is flipped in the portal.

Creating a GitHub release is outward-facing and hard to undo. Confirm the version with the user and get an explicit go-ahead before step 5.

Inputs

• VERSION: the tag, vX.Y.Z (or vX.Y.Z-beta1 for a dry run). If the user didn't give one, ask. Decide the bump (patch vs minor vs major) now, from what actually landed since the last release. Do not pre-empt it earlier.
• PREV: the previous release tag. It is only the compare base for the "Full changelog" link at the bottom of the notes; the notes themselves come from the changelog entry. Get it with gh release list --limit 5 or git tag --sort=-v:refname | head.

1. Draft the changelog and get it approved (always first)

Before any release mechanics, show the user what the release will say. This is the gate that lets them see, and shape, what's going into the upcoming release.

• Gather what shipped since PREV: git log PREV..origin/develop --oneline plus the merged PRs (gh pr list --state merged --base develop). Keep only user-visible changes, per the changelog skill's rules (.claude/skills/changelog/SKILL.md).
• Build the draft from the staging entry in frontend/src/changelog.ts if one exists, folding in anything that landed since it was last updated. If there's no staging entry, draft one from scratch using the changelog skill. Follow docs/WRITING_STYLE.md.
• Present the full draft in chat: headline, intro, every section, outro. Also list anything you judged NOT worth mentioning, so the user can veto that judgement.
• Wait for the user to approve or request edits. Apply edits and re-present until they explicitly approve. Do not start pre-flight, and do not touch main, until the draft is approved.
• Once approved, write the result back to the staging entry in frontend/src/changelog.ts (still released: false); step 3 promotes it.

2. Pre-flight

• git fetch --all --tags.
• Confirm develop is the integration branch and is green (latest CI passing).
• Confirm main can fast-forward from origin/develop (git merge-base --is-ancestor origin/main origin/develop). If it can't, stop and tell the user: main has diverged and just release will fail its --ff-only merge.
• Working tree clean, and HEAD on the commit that is about to become main (just release aborts on either count). gh auth status OK.

3. Promote the changelog (this is what the release notes ARE)

Two things depend on this entry. The shipped binary carries its own changelog and matches it to its version at runtime, so it becomes "What's new" after the update. And just release renders the same entry into the GitHub release body, which the workflows post to the portal and the update dialog shows under "What's changed" before the update.

So the entry must be promoted and pushed before step 5. If it isn't, just release fails at the first command with "No released changelog entry for X.Y.Z" and nothing is tagged. So:

• In frontend/src/changelog.ts, take the approved staging entry from step 1 and promote it: set released: true, version to the bare semver ("X.Y.Z", no v, must match VERSION), and date to "Month YYYY".
• Give it a real headline if it still has the placeholder.
• The content itself was approved in step 1; don't rewrite it here beyond the promotion fields.

Then validate and land it on develop:

cd frontend && pnpm test:run changelog && pnpm check
git add -A && git commit -m "chore(changelog): notes for VERSION"
git push origin develop

The commit must be on develop and pushed before step 5, because just release fast-forwards main from origin/develop.

Then read back exactly what the release will say:

just release-notes VERSION PREV