Standardize Rust releases with release-plz

[Teakowa]

Goal

Establish an evidence-backed WrightKit-wide default for releasing Rust repositories with release-plz, reducing custom release machinery while preserving each repository's product-specific release contracts.

Context

WrightKit initially implemented a custom one-click release workflow in workshop-rs because release-plz was assumed to require manual release PR/tag handling. Current release-plz capabilities invalidate that premise: it can maintain release PRs, determine/version packages, publish crates where appropriate, create Git tags, and create GitHub Releases. Repository-specific binary packaging and other product artifacts remain separate concerns.

workshop-rs#14 is valid historical evidence for the desired maintainer UX, but the custom implementation should now be treated as a baseline to compare against rather than a pattern to copy across WrightKit.

Two complementary migrations now provide evidence:

• workshop-rs#29 covers a workspace that publishes crates.io packages and native CLI artifacts;
• wright#166 covers a multi-crate Rust product whose canonical public distribution is GitHub/native/npm/package-manager based and therefore should use release-plz's git-only release management rather than publishing internal crates.

Scope

• Define the preferred WrightKit release model for Rust repositories around release-plz:
  • automatically maintained Release PRs;
  • release only after the intended Release PR is merged rather than on every merge to main;
  • automatic Cargo version/lockfile/changelog management where applicable;
  • crates.io publication only for repositories/packages that intentionally publish there;
  • git-only release management for Rust products that do not publish their internal crates;
  • Git tag and GitHub Release creation;
  • workspace/version-group handling and a single product release identity where appropriate;
  • explicit handling of GitHub token/event-trigger limitations when downstream binary/artifact jobs are required.
• Use wrightkit/workshop-rs and wrightkit/wright as complementary implementation evidence rather than assuming one workflow shape fits both.
• Keep repository-specific artifact building, checksums, provenance/catalog identity, npm/package-manager publication, platform matrices, and other product release outputs in the owning repository.
• After these implementations provide real release evidence, evaluate whether the pattern should be adopted independently by opy-rs, del-rs, and other publishable Rust repositories.
• Record the durable cross-repository policy in .github only after implementation evidence confirms the useful common denominator.

Non-goals

• Migrating every Rust repository immediately.
• Forcing repositories with different release products to use identical workflow YAML.
• Releasing every merge to main.
• Publishing internal/non-product crates merely to satisfy release-plz defaults.
• Treating release-plz as the owner of binary packaging or repository-specific release artifacts.
• Freezing a shared reusable workflow before repeated repo-local usage demonstrates that abstraction is useful.
• Changing semantic-versioning policy solely to match release-plz defaults without repository evidence.

Acceptance criteria

• workshop-rs#29 demonstrates the intended maintainer UX for a crates.io + binary workspace: release-plz prepares/updates a Release PR, merging it initiates the normal release path, intended crates publish coherently, and repository-specific artifacts remain intact.
• wright#166 demonstrates the same maintainer UX for a git-only product workspace without accidentally publishing internal crates, while preserving Wright's native/npm/package-manager release contract.
• Both implementations preserve one coherent product release identity and existing quality/release gates.
• The release designs explicitly account for GitHub Actions token/event-trigger behavior rather than relying on tag/Release events that the default GITHUB_TOKEN cannot trigger.
• Each implementation is compared against its previous custom workflow on maintainability, recovery behavior, permissions, and release UX.
• The resulting organization-level guidance distinguishes at least Cargo-published packages from git-only Rust product workspaces instead of prescribing one undifferentiated configuration.
• Any later migration is tracked and implemented in the repository that owns the release workflow.

Dependencies

• wrightkit/workshop-rs#14 — current custom one-click release baseline.
• wrightkit/workshop-rs#29 — crates.io + binary release-plz migration.
• wrightkit/wright#166 — git-only Wright product release-plz migration.

Planning notes

Prefer release management as maintained ecosystem infrastructure and keep WrightKit code focused on repository-specific release requirements. Do not preserve custom version/tag/publish orchestration merely because it already exists if release-plz can own that responsibility more reliably. Derive any reusable workflow only after both migration shapes reveal the stable common contract.