Releasing

Releasing

For maintainers. A release puts ready-to-run downloads for Windows, Mac and Linux on the Releases page.

1. Prepare

1. Bump the version in Cargo.toml ([workspace.package] version), apps/where_flutter/pubspec.yaml, and the version labels in the app (browser_bridge.dart, settings_page.dart).
2. Move the Unreleased notes in CHANGELOG.md under the new version.
3. Write docs/releases/vX.Y.Z.md. The first line (# Title) becomes the release name, and the rest becomes the notes. Without this file, the CHANGELOG section is used.
4. Commit and push to main.

2a. Automatic: let GitHub build everything

git tag -a vX.Y.Z -m "Where X.Y.Z"
git push origin vX.Y.Z

The Release workflow builds on GitHub's machines:

Job	Makes
Windows	Where-Setup-X.Y.Z-windows-x64.exe, …-windows-x64-portable.zip
macOS	…-macos-universal.dmg and .zip
Linux x64 and arm64	.AppImage, .deb, .tar.gz
Extension	…-browser-extension.zip

Then it publishes the release with all files attached. Watch it under Actions → Release.

2b. By hand, from Windows

Double-click make-release.bat (after building with start-where.bat):

make-release.bat                 :: release the version in Cargo.toml
make-release.bat -Fetch          :: also download GitHub's Mac/Linux builds
make-release.bat -Draft          :: publish as a draft first
make-release.bat 0.5.0 -Fetch    :: a specific version

It zips the Windows app (with the C++ runtime, extension, LICENSE and NOTICE), builds the installer, adds the extension zip and anything in release-files\ (for example a .dmg built on a Mac), then creates or updates the GitHub release with the notes from docs\releases\. It uses the GitHub CLI (gh) and installs it if needed. Build output goes to dist\, which is never committed.

3. Check

• Download each file on a real computer and open Where.
• Make sure the release notes' download table matches the files.
• Update the Notion roadmap and the wiki if anything changed for users.