Releases and signing

You cut every release from main. A conventional-commit PR title decides the next version, and a single workflow builds, signs, and publishes the macOS and Windows binaries once that version is set.

Branching and the release PR

You develop on dev and merge to main through a PR. Once your PR title follows the feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert convention, release-please reads the commit history on main and opens or updates a release PR with the next version and changelog. Merge that PR and it creates a draft GitHub Release and its tag. chore commits produce no version bump, so a release cut relies on the other commit types being used correctly.

For a hotfix, skip the normal flow:

1. Branch hotfix/<desc> from main.
2. Land only a fix(scope): ... commit.
3. Merge it. This lets release-please open a patch-bump PR.
4. Cherry-pick the fix back into dev.

After a release publishes, dev gets reset to match main so the two branches don’t drift.

From tag to published binaries

Once you merge the release PR, it triggers the desktop release workflow, described in full on CI/CD. It builds the app for macOS Apple Silicon, macOS Intel, and Windows, cross-compiles the CLI for three targets, signs the Tauri updater output, and uploads every asset to the draft release. A verification script then checks the draft has the full expected set of signed and unsigned assets before flipping it to a live release.

Updates ship through a single stable channel served from GitHub Releases. The version comparator only moves users forward: there is no rollback API.

Code signing and binary authenticity

You sign every Mach-O bundled into the macOS app, including the CLI, Node.js, and the Swift helpers, individually with a Developer ID Application certificate, Hardened Runtime, and a secure timestamp, then notarize the bundle with Apple before it ships. Tauri’s updater signatures use a separate Ed25519 key. Binary authenticity explains what each layer stops and why the Developer ID certificate is the one you protect most carefully.

You haven’t shipped Windows code signing yet. You’ll use Azure Artifact Signing (HSM-backed cloud signing) rather than a local certificate file once it lands.

Setting up the signing certificate and rotating credentials after a leak are operational tasks outside this page.