Release 0.22.0

[afilini]

Create a new minor release

Summary

This release brings support for hardware signers on desktop through the HWI library.

It also includes fixes and improvements which are part of our ongoing effort of integrating
BDK and LDK together.

Commit

32db387

Changelog

Added

• Functions to create FeeRate from sats/kvbytes and sats/kwu. Implement conversion for Lightning fee rate #678
• Custom hardware wallet signer HwiSigner in wallet::hardwaresigner module. Add a custom signer for hardware wallets #682
• Function allow_dust on TxBuilder. Add allow_dust method to TxBuilder #689
• Implementation of Deref<Target=UrlClient> for EsploraBlockchain. Implement Deref<Target=UrlClient> for EsploraBlockchain #722
• Implementation of Deref<Target=Client> for ElectrumBlockchain Implement Deref<Target=Client> for ElectrumBlockchain #705
• Implementation of Deref<Target=Client> for RpcBlockchain. Implement Deref<Target=Client> for RpcBlockchain #731

Changed

• FeeRate function name as_sat_vb to as_sat_per_vb. Implement conversion for Lightning fee rate #678
• Verify signatures after signing. Verify signatures after signing #718
• Dependency electrum-client to 0.11.0. Update electrum-client to 0.11.0 #737

Checklist

Release numbering must follow Semantic Versioning. These steps assume the current master
branch development version is MAJOR.MINOR.0.

On the day of the feature freeze

Change the master branch to the next MINOR+1 version:

• Switch to the master branch.
• Create a new PR branch called bump_dev_MAJOR_MINOR+1, eg. bump_dev_0_22.
• Bump the bump_dev_MAJOR_MINOR+1 branch to the next development MINOR+1 version.
  • Change the Cargo.toml version value to MAJOR.MINOR+1.0.
  • The commit message should be "Bump version to MAJOR.MINOR+1.0".
• Create PR and merge the bump_dev_MAJOR_MINOR+1 branch to master.
  • Title PR "Bump version to MAJOR.MINOR+1.0".

Create a new release branch and release candidate tag:

• Double check that your local master is up-to-date with the upstream repo.
• Create a new branch called release/MAJOR.MINOR+1 from master.
• Add a tag to the HEAD commit in the release/MAJOR.MINOR+1 branch.
  • The tag name should be vMAJOR.MINOR+1.0-RC.1
  • Use message "Release MAJOR.MINOR+1.0 RC.1".
  • Make sure the tag is signed, for extra safety use the explicit --sign flag.
• Push the release/MAJOR.MINOR branch and new tag to the bitcoindevkit/bdk repo.
  • Use git push --tags option to push the new vMAJOR.MINOR+1.0-RC.1 tag.

If any issues need to be fixed before the MAJOR.MINOR+1.0 version is released:

• Merge fix PRs to the master branch.
• Git cherry-pick fix commits to the release/MAJOR.MINOR+1 branch.
• Verify fixes in release/MAJOR.MINOR+1 branch.
• Add a tag to the HEAD commit in the release/MAJOR.MINOR+1 branch.
  • The tag name should be vMAJOR.MINOR+1.0-RC.x+1, where x is the current release candidate number.
  • Use tag message "Release MAJOR.MINOR+1.0 RC.x+1".
  • Make sure the tag is signed, for extra safety use the explicit --sign flag.
• Push the new tag to the bitcoindevkit/bdk repo.
  • Use git push --tags option to push the new vMAJOR.MINOR+1.0-RC.x+1 tag.

On the day of the release

Tag and publish new release:

• Add a tag to the HEAD commit in the release/MAJOR.MINOR+1 branch.
  • The tag name should be vMAJOR.MINOR+1.0
  • The first line of the tag message should be "Release MAJOR.MINOR+1.0".
  • In the body of the tag message put a copy of the Summary and Changelog for the release.
  • Make sure the tag is signed, for extra safety use the explicit --sign flag.
• Wait for the CI to finish one last time.
• Push the new tag to the bitcoindevkit/bdk repo.
• Publish all the updated crates to crates.io.
• Create the release on GitHub.
  • Go to "tags", click on the dots on the right and select "Create Release".
  • Set the title to Release MAJOR.MINOR+1.0.
  • In the release notes body put the Summary and Changelog.
  • Use the "+ Auto-generate release notes" button to add details from included PRs.
  • Until we reach a 1.0.0 release check the "Pre-release" box.
• Make sure the new release shows up on crates.io and that the docs are built correctly on docs.rs.
• Announce the release, using the Summary, on Discord, Twitter and Mastodon.
• Celebrate 🎉

[notmandatory]

I added changelog notes in the description, feel free to edit.

[notmandatory]

@afilini in the new release/0.22 branch you set the Cargo version to 0.22.0-rc.1 can we change that to 0.22.0 ? this allows downstream projects to test with the version set to 0.22 and patch to the tag 0.22.0-rc.1 (removing patch once 0.22.0 is published). This is mainly useful later if we have to publish a 0.22.1 it will allow downstream projects to patch the their bdk to 0.22.1 before it's published on crates.io.

[afilini]

I don't think it really matters here if we use the -rc suffix. It's only with patch-level releases that we should be careful not to use them to let other projects use cargo patches. Basically we want to let people who are, say, on 0.22 to patch and try some fixes before they are released as 0.22.1.

But the upgrade to 0.22 itself must be a manual process, because the API is different from 0.21. For the same reason, cargo doesn't allow you to use patches to "update" dependencies, if you are currently on 0.21 you can't patch and point to 0.22.

Also note that patches aren't "inherited" in downstream projects: for example, if crate a depends on bdk, and crate b depends on a, if a uses patches to change the version of bdk they won't be inherited by b. b would have to also apply the same patches to their Cargo.toml. That is to say, patches are only meant to be used for a quick test, but they don't replace properly updating the dependencies.

[notmandatory]

OK sounds fine, anyway I think we'll have a better patching (and merging) experience going forward. :-D

[notmandatory]

Downstream update PRs:

• Update bdk dependency to 0.22 bdk-reserves#11
• Update bdk dependency to 0.22 bdk-cli#118
• Update bdk dependency to 0.22 bdk-ffi#193

[afilini]

I just noticed that the -rc.1 and -rc.2 tags are missing the "v" prefix. I'll keep them like this right now because I don't want to break all the PRs, but maybe in the future we can think about renaming them, once it's likely nobody is using them anymore.

[afilini]

I also updated the changelog to include PR numbers

[notmandatory]

Looks good, and good idea to add the PR #s to the change log. I also added a copy of the "Summary" and "Changelog" to the GitHub release page, and renamed the github auto-generated changelog to "All Changes". I'll get the downstream projects update PRs ready today. Up to you if you think it's worth renaming the -rc.* tags, now that the release it out no one should need them.