Release

Seven steps; stable comes later, when the user says so. Each has a gate, do not start the next one until the gate is green. Report the version, the run URLs and the gate results as you go; ask before skipping a step.

0. Preflight

git switch main && git pull --ff-only
git status --short          # must be empty

1. Does server/ need a release first?

The desktop app downloads a pinned engine, so engine fixes only reach users through a new server release.

pin=$(cat .server-version)                          # e.g. v0.6.9
git log --oneline "server-${pin#v}"..main -- server/ 2>/dev/null ||
  git log --oneline "server-$pin"..main -- server/

• No commits → skip to step 2, leave .server-version alone.
• Only docs/comments → say so and ask whether to skip.
• Code changed → release the server first:
  • If anything under server/libs/ changed (ggml-version, patches/, libs.chore, include/), bump server/libs/revision in the same commit and run server-libs.yml first (~9 min); upload-libs refuses a tag that exists for another tree.
  • git tag server-vX.Y.Z && git push origin server-vX.Y.Z on main.
  • Gate: server-release.yml green (~8 min) and all 5 assets uploaded, the Intel Mac asset lands last. It publishes as a prerelease on purpose; leave it that way so Latest stays with the app.

2. Bump and write the notes

Three files, one commit:

• desktop/src-tauri/tauri.conf.json → "version".
• .server-version → the new server tag minus server- (only if step 1 released one).
• i18n/changelog/<version>.md. release.yml fails without it.