Releasing

Releases are automated end to end. The moving parts:

1. Commits on main follow Conventional Commits. fix: bumps the patch version, feat: bumps it too while the project is pre-1.0, and a breaking change bumps the minor version.
2. release-please watches main and keeps a release pull request open, accumulating the changelog and the version bump (the workspace version in Cargo.toml, plus version.txt). A companion job refreshes Cargo.lock on that branch.
3. Merging the release pull request dispatches the build. No tag or release exists yet, so releases/latest keeps serving the previous version while binaries build.
4. The release workflow (generated by cargo-dist) builds binaries for macOS (Apple silicon and Intel), Linux (x86_64 and aarch64, so a Raspberry Pi installs the same way), and Windows, then creates the vX.Y.Z tag and the GitHub release together with the checksummed binaries and the shell and PowerShell installers, in one step. latest flips atomically; a failed build creates nothing at all. The next release pull request is generated once the release exists (release-please reruns when the pipeline completes).

Cutting a release

• Check that the latest ci and docs runs on main are green. A release must never ship from a red tree.
• Open the release pull request, read the generated changelog, and merge it.
• Watch the release workflow. When it finishes, the new version is live at the releases/latest URLs the install instructions point to.

Verifying

curl -fsSL https://github.com/sean-reid/miditool/releases/latest/download/miditool-installer.sh | sh
miditool --version

The version printed must match the tag that just shipped.