[notmandatory]

Description

Adds manually triggered release-plz automation for all workspace crates.

• Adds .github/workflows/release-plz.yml:
  • release-pr opens/updates a release PR with version bumps and CHANGELOG.md updates for each changed crate.
  • release publishes unpublished crates to crates.io via OIDC trusted publishing (no registry token), creates <crate>-<version> tags, and creates GitHub releases. Publishing is gated by the release environment.
• Adds release-plz.toml to:
  • Preserve bdk's existing tag naming, e.g. chain-0.23.4.
  • Keep a separate CHANGELOG.md for every workspace crate.
  • Only publish after the release PR is merged (release_always = false).
  • Add the release label to release PRs.
• Updates DEVELOPMENT_CYCLE.md with the new release process.
• Removes the manual minor_release.md and patch_release.md issue templates.
• Removes the changelog section from the PR template and updates crate changelog headers to note they are generated from Conventional Commits.
• Bumps actions-rust-lang/setup-rust-toolchain from v1 to v2 for consistency with the new workflow and the referenced bdk-cli change.

Notes to the reviewers

This is based on bitcoindevkit/bdk-cli#335.

The workflow is manual-only, so merging this PR does not publish anything. release-plz supports only one open release PR per repository.

Before the first release, these settings are required:

• The RELEASE_PLZ_APP_ID and RELEASE_PLZ_PRIVATE_KEY secrets must be available to this repository, and the GitHub App must be installed here with Contents and Pull requests read/write permissions.
• A release environment with required reviewers.
• crates.io trusted publishing configured for all seven crates with workflow release-plz.yml and environment release.

The first run should be from a release/* branch or after syncing master with crates.io, because master's crate versions currently lag the published versions (for example bdk_chain is 0.23.2 on master vs 0.23.4 on crates.io). This is documented in DEVELOPMENT_CYCLE.md.

Existing release/chain-0.23.x branches do not contain the new workflow file; it must be added there before running release-plz on that branch.

Two behavior changes to note:

• release-plz creates tags through the GitHub API, so tags are not GPG-signed.
• release-plz creates its release PR commit through the GitHub API, which GitHub marks as Verified.

The setup-rust-toolchain bump is not required by release-plz; it was carried over from the bdk-cli PR and can be dropped if we want this PR narrowly scoped.

Checklists

All Submissions:

• I followed the contribution guidelines

New Features:

• I've added docs for the new feature

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.62%. Comparing base (c5e87cc) to head (541c15b).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2448   +/-   ##
=======================================
  Coverage   83.62%   83.62%           
=======================================
  Files          31       31           
  Lines        6339     6339           
  Branches      292      292           
=======================================
  Hits         5301     5301           
  Misses        970      970           
  Partials       68       68           

Flag	Coverage Δ
rust	83.62% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[oleonardolima]

we should keep this in the PR template, so the author fill it with proper changes from their PRs

[notmandatory]

I'd also rather use the PR review to enforce good commit messages instead of using this section of the PR which often needs to be re-worded by the release team anyway. I'm hoping once everyone gets in the habit of using commit messages for the changelog the release process will require much less manual work.

[notmandatory]

I've also created an LLM skill that I'll post somewhere in the .github repo that does a good job of cleaning up the repo CHANGELOGs.

[oleonardolima]

I'm not sure if it's a good idea to have this being auto-generated, I mean not unless we have another CI step enforcing conventional commits usage on every commit.

[notmandatory]

The CONTRIBUTING guide already lets people know that commit messages should follow the conventional commits style. And even with the release-plz action the auto-generated release PR with the changelog can still be edited by hand before merging and doing the actual release.

As for enforcing conventional commits with a CI step, I'd rather not hold this PR up for that since we can enforce it manually for now.

[notmandatory]

I did a test run in my fork of this repo to show what the release PR created by release-plz looks like. I also added a commit to show what a little LLM generated cleanup of the change logs looks like. See:

notmandatory#30

[notmandatory]

I did a little search for conventional commits linting tools and there are a few out there, but I didn't find any that are widely used. Also they all have a lot of dependencies for a simple task. Checking commit messages should be something easy to do manually and/or make sure an LLM reviewer checks, which they should already do if they read the CONTRIBUTING.md file.

[tvpeter]

Thank you for working on this @notmandatory .

I have left some coments.

[tvpeter]

ACK 541c15b

Thank you.

[notmandatory]

Updated release PR with LLM improved CHANGELOGs here: notmandatory/bdk#33

[notmandatory]

The agent SKILL I used to cleanup the release-plz generated CHANGELOGs is here: bitcoindevkit/.github#125