Use release-plz for releases?

[LegNeato]

This seems like it might be better than manually triggering releases:

https://github.com/release-plz/release-plz

[Firestar99]

For posterity sake, here were my opinions on cargo-smart-release (NOT release-plz):

• it contains cargo changelog, a tool to extract a changelog from git commits when they are formatted like Conventional Commits
• cargo-smart-release generates these changelogs, commits them, and forwards to cargo release
• whether to do a patch, minor or major release is derived from there being BREAKING CHANGE: or <type>! commits
• unlike cargo-release, it does not package and test packages build on dry run by default, that's opt-in and labeled as potentially unstable. Which just like cargo release's dry-run, which fails in the rust-gpu repo due to using an outdated lib from crates instead of the local one.

Problems with our codebase:

• we never used Conventional Commits
• the changelog it generates is thus an unreadable mess
  • it doesn't know about old releases, so the entire git history in is this release
  • since we don't use fix:-like tags, everything is in category ### Other
  • about a third of commits is associated an issue, but not a PR
    • the issue links go to our repo, even if they were embark issue IDs
• it thinks we should do a patch, since there are no commits marked as breaking changes (we can overwrite that in the cmdline)
• it has a changelog per-crate, we have one in the repo root (which makes a lot more sense for us), no way to customize that
• supports manual edits, but only saves manual changes once you release (eg. won't touch old releases)
• changelogs for rustc_codegen_spirv and spirv-std

TLDR: I think we are better served by a manual changelog, since there are so many internal changes our end users won't care about. They only want the user-facing changes in the changelog, so I'd recommend manually making one, even if it's more work atm. And using cargo release directly, I'm gonna set it up now, and even if we switch to smart-release we can still use it.
We could think about changing our commit style and switching to cargo-smart-release for future releases or with new projects, but I wouldn't for this release. Also we'd need a single global changelog for rust-gpu.

[Firestar99]

This is release-plz comparing itself to smart-release:

Conventional commits aren't required 👍

Release-please requires conventional commits to work. For example, it only generates a release PR if your commit messages start with fix:, feat:, or deps: (there are some exceptions based on the language).
Release-plz, instead, generates a release PR for every commit affecting one of your packages, regardless of the commit message. Release-plz also generates a release PR if you change the dependencies of your packages (either in the Cargo.toml or in the Cargo.lock files).

This already sounds a lot more promising