chore: automate version bumps and releases with release-plz

[sosaucily]

👋 This is a proposal from the BitSafe tooling side, opened as a draft for you to
evaluate — not something we plan to merge without your say. Happy to close it if the
trade-offs don't suit this repo.

The problem

The workspace version lives on one line in Cargo.toml. Two open PRs that both bump it
always conflict, and re-bumping after a review trips dismiss_stale_reviews_on_push —
so the approval is lost. Because require_last_push_approval is on, whoever pushes the
bump can't be the one to approve it either.

This repo's history shows the resulting toil — four separate manual bump commits:

chore: bump version to 0.6.1 (#24)
chore: bump version to 0.6.0 (#20)
Bump version to 0.5.0 (#15)
Bump version to 0.4.0 (#10)

What this changes

release-plz maintains one rolling release PR that bumps
the workspace version and writes CHANGELOG.md, derived from the Conventional Commit
prefixes since the last tag. Merging that PR cuts the release and tags it.

A normal PR stops touching the version entirely. No conflicts, no dismissed approvals.

Two files, no changes to any crate:

File	What
.github/workflows/release-plz.yml	Two jobs — open/update the release PR, and tag on merge
release-plz.toml	Config: no crates.io publishing, existing tag scheme, two exclusions

Why release-plz and not release-please

We use release-please elsewhere, but its Cargo workspace support needs the
cargo-workspace plugin plus a manifest entry per crate, and has known gaps.
release-plz is Rust-native and handles a shared [workspace.package] version directly,
which is exactly your layout.

It is safe to merge and watch

The release job only acts when the version in Cargo.toml has no matching git tag.
You're at 0.6.1 and v0.6.1 already exists, so merging this changes nothing
immediately. The first push to main afterwards opens a release PR you can read, inspect,
and close if you hate it. Nothing is tagged or published until you merge that PR.

Decisions that are yours, not ours

1. CHANGELOG.md ownership — the big one. You currently hand-maintain it in
Keep a Changelog format with an ## [Unreleased] section.
release-plz will take over writing this file, and its default output is grouped by commit
type rather than by Added/Changed/Fixed. It's configurable
via git-cliff templates if you want to preserve the current shape, but we didn't presume
to restyle your changelog — tell us what you want and we'll wire it up, or you can keep
the file hand-written by setting changelog_update = false.

2. Conventional Commits become load-bearing. The version bump is derived from feat: /
fix: / feat!: prefixes. Your recent history already does this (feat(registry):,
feat(keycloak):, fix:), but older commits don't (Add breaking change note, Fix the serialization). Since PRs here squash-merge, the PR title is what gets read — so this
is a PR-title convention, not a per-commit one. Untyped commits simply don't bump anything.

3. This is the repo's first workflow. There's no .github/workflows/ today. If you'd
prefer CI to land before release automation, this can wait.

Config notes

• publish = false — consumed as a git dependency, so no crates.io publish and no
  CARGO_REGISTRY_TOKEN. Only the built-in GITHUB_TOKEN is used.
• git_tag_name = "v{{ version }}" — matches your existing v0.6.1 scheme. Without
  it, release-plz would tag per crate (wallet-v0.6.2).
• canton-proto-rs excluded (release = false) — it pins its own upstream version
  3.4.0 rather than inheriting version.workspace, so it must not move with the
  workspace.
• examples excluded — publish = false already, and not public API.
• Both actions are SHA-pinned (actions/checkout v4.2.2, release-plz/action
  v0.5.131).

What we verified, and what we didn't

Verified locally: the workflow YAML and release-plz.toml both parse; the config keys are
from the current docs; and the crate classification is correct — 6 crates inherit
version.workspace and are managed, 2 are excluded.

Not verified: the actual behaviour of the first run, specifically whether the shared
workspace version produces the single v0.6.2 tag we intend rather than one per crate.
That's precisely what the first release PR will show, and it's inspectable before you merge
it. We'd rather flag this than claim it's turnkey.

One more to confirm on the first release PR: this repo requires signed commits on main.
PR merges are signed by GitHub, so we expect this to be fine, but worth a look.

🤖 Generated with Claude Code