Releasing

Releasing

This page is for maintainers. It summarizes how a release works. The full guide, with every command, is docs/RELEASING.md. The reasons behind the process are in section 9 of the development plan.

No release exists yet. Until the beta channel opens in Phase 13, releases are test builds, and some checklist items, such as code signing, can't pass yet.

The short version

1. Check the release checklist.
2. Bump the version in three files, and merge the change to main.
3. Tag the merge commit, such as v0.5.0, and push only that tag.
4. Watch the release workflow on GitHub, then verify the release.

Nobody builds or uploads anything by hand. Avoid git push --tags, because each new v tag can start its own release.

One-time setup

Step	What to do
Create the update signing key	Run npx tauri signer generate, choose a strong password, and store the private key and password in a password manager, with an offline backup
Add two repository secrets	TAURI_SIGNING_PRIVATE_KEY and TAURI_SIGNING_PRIVATE_KEY_PASSWORD. Only the signing step receives them.
Add code signing	Optional for now. An Authenticode certificate, such as one from Azure Trusted Signing, stops SmartScreen warnings. The checklist requires it before the first beta.

Never commit the private key. If it leaks, generate a new pair, ship one last release that carries the new public key, and replace both secrets.

Versions

OpenNote follows semantic versioning: major.minor.patch. A fix bumps the patch number, a new feature bumps the minor number, and a break in compatibility bumps the major number. Before 1.0.0, a minor version may also break compatibility. A tag with a hyphen, such as v0.5.0-beta.1, makes a prerelease.

The version lives in package.json, app/src-tauri/Cargo.toml, and app/src-tauri/tauri.conf.json. All three must match the tag. The release workflow stops in seconds if they don't.

Release files

File	For
OpenNote_Windows64.exe	64-bit Windows, on most PCs
OpenNote_Windows32.exe	32-bit Windows
OpenNote_WindowsARM64.exe	Windows on ARM64 PCs
<exe name>.sig	The update signature for each exe
latest.json or beta.json	The manifest that running copies read to find updates

What the workflow does

Pushing a tag that starts with v runs release.yml. It has four jobs, and each starts only when the one before succeeds.

Job	What it does
version	Checks that the tag matches all three version files
ci	Runs the same checks and tests as a push to main
build	Builds the three exes side by side on Windows, with no secrets
publish	Signs each exe, writes the manifest, and publishes the GitHub Release

Only the publish job can write to the repository, and only its signing step receives the secrets. A release is never published unsigned.

After the workflow

Verify the release right away, because it goes live with no draft step. Check that it lists the three exes, a .sig for each, and the manifest. Check each exe's hash and size against the manifest, and run each exe on Windows. Then rewrite the generated release notes for people who use the app.

If the workflow fails before "Publish the release", nothing is published. To roll back a bad release, mark it as a prerelease, or delete it and keep the tag. Then publish a fixed patch version. Never move the tag of a published release.

Related pages

• Installing and updating, for what people see
• Development process
• Testing and quality