Skip to content

Releasing

Releases are cut by the maintainer when the merged work since the last tag adds up to something a user would notice. Never on a fixed schedule.

  1. Open an issue for the release, then a branch.
  2. Move the entries under ## [Unreleased] in CHANGELOG.md into a new ## [x.y.z] - YYYY-MM-DD section and update the compare links at the bottom.
  3. Bump version in crates/mohar-core/Cargo.toml and crates/mohar-cli/Cargo.toml, and the mohar-core version that mohar-cli depends on. Run cargo check so Cargo.lock follows.
  4. Open the pull request. The Release workflow runs dist plan on it, so a broken release configuration fails before anything is tagged.
  5. After it merges and main is green, tag the merge commit and push the tag:
git tag -a vX.Y.Z -m "vX.Y.Z"   # use -s instead once a signing key is set up
git push origin vX.Y.Z

Only admins can create v* tags. 6. The Release workflow (generated by cargo-dist; regenerate with dist generate after editing dist-workspace.toml, never by hand) builds mohar for Linux and macOS on x86_64 and arm64 and for Windows on x86_64, writes shell and PowerShell installers and checksums, attests build provenance, and publishes the GitHub Release with the changelog section as its notes. 7. Check one artefact's provenance:

gh attestation verify mohar-cli-x86_64-unknown-linux-gnu.tar.xz -R harshitwandhare/mohar

Upgrading cargo-dist: change cargo-dist-version, run dist generate, and re-check .github/zizmor.yml, whose accepted findings point at line numbers in the generated file.