bump-version

Bump version — cut a termio release

termio is trunk-based: a release is nothing but a vX.Y.Z tag on main. Pushing the tag fires .github/workflows/release.yml (the Release workflow), which signs, notarizes, packages the DMG, updates the Sparkle appcast, and uploads to Cloudflare R2. There is no merge and no release branch.

Follow these steps in order. Stop and report if any precondition fails — never force past a failed check.

1. Preconditions

git switch main
git pull --ff-only
git status --short          # release-relevant work must be committed
git rev-parse --abbrev-ref HEAD    # must print: main

• Must be on main and even with origin/main (the tag ships whatever main points at right now).
• The working tree may have unrelated untracked scratch files, but anything meant for this release must already be committed and pushed.

2. Pick the next version

Read the current version and compute the next one:

git tag --list 'v*' --sort=-v:refname | head -1     # e.g. v0.13.1

Decide X.Y.Z (semver, no v when talking, v in the tag):

• Explicit version from the user (e.g. "0.14.0") → use it verbatim.
• A bump keyword → apply it to the latest tag: patch (0.13.1→0.13.2), minor (0.13.1→0.14.0), major (0.13.1→1.0.0).
• Nothing specified → propose the bump you believe fits (termio has used minor for features, patch for fixes) and confirm the number with the user before tagging.

The version must only ever go up — the build number is git rev-list --count HEAD, and Sparkle treats a lower CFBundleVersion as older, which breaks auto-update. Never reuse or lower a version.

3. Write the changelog entry

The site's changelog is web/landing/src/data/changelog.ts, newest entry first. Add the entry for the version you are about to tag before tagging — the Docs workflow fails once a tag exists without one, and a changelog that trails the releases makes the site read as abandoned.