Release 1.0.0-alpha.1

[notmandatory]

Create a new alpha release

Summary

The BDK 1.0.0-alpha release should be used for experimentation only, APIs are still unstable and the code is not fully tested. This alpha.1 release introduces the new ChainOracle struct for more efficient chain syncing. A new std default feature was added for bdk, bdk_chain and bdk_esplora crates; when disabled these crates can be used in no-std projects. BDK 1.0.0-alpha.x docs are now published to docs.rs.

Commit

f4d2a76

Changelog

Fixed

• Fixed a bug in the policy condition calculation. Fix policy condition calculation #932
• Pin base64 to 0.21.0 Pin base64 to 0.21.0 to keep the MSRV to 1.57.0 #990
• Fix docsrs publishing for bdk crate. [ci] fix docsrs error for bdk crate #1011

Changed

• Refactor bdk_chain to use new ChainOracle structure. Introduce redesigned bdk_chain structures #926 Various tweaks to redesigned structures #963 Implement persistence with the new structures #965 Improve txout listing and balance APIs for redesigned structures #975 Reimplement Wallet, ElectrumExt and Esplora{Async}Ext with redesigned structures. #976
• Better no std support. Better no-std support #894
  • Set default-features = false for rust-bitcoin and rust-miniscript.
  • Introduce std default feature for bdk, bdk_chain and bdk_esplora.

Added

• Add a simple conversion tool for going to kilo weight units. Add sat_per_kwu to FeeRate #953
• Add Custom spk iterator. Custom spk iterator #927
• Add taproot descriptor template (BIP-86). create taproot descriptor template #840

Checklist

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

Before publishing the release

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

• Switch to the master branch.
• Create a new PR branch called bump_dev_1.0.0-alpha.1.
• Bump the crates versions and README files
  • bdk to 1.0.0-alpha.1.
  • bdk_chain to 0.5.0
  • bdk_electrum to 0.3.0
  • bdk_esplora to 0.3.0
  • bdk_file_store to 0.2.0
• Bump the example-crates versions and README files
  • example_cli to 0.2.0
  • example_electrum to 0.2.0
  • wallet_electrum_example to 0.2.0
  • wallet_esplora to 0.2.0
  • wallet_esplora_async to 0.2.0
• Commit the changes with message "Bump version to 1.0.0-alpha.1".
• Create PR and merge the bump_dev_1.0.0-alpha.1 branch to master.
  • Title PR "Bump version to 1.0.0-alpha.1".

On the day of the release

Tag and publish new release:

• Add a tag to the HEAD commit in the master branch.
  • The tag name should be v1.0.0-alpha.1
  • The first line of the tag message should be "Release 1.0.0-alpha.1".
  • 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 1.0.0-alpha.1.
  • 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 Nostr.
• Celebrate 🎉

[LLFourn]

We need to update bitcoin 0.30.0 and miniscript 10.0.0 to latest versions as well

#916 <-- there's an issue about sending hate mail but I didn't find separate issue for this.

[notmandatory]

@LLFourn we should get on the same page about alpha releases, my hope is that we could do smaller but more frequent alphas to help organize the teams 1.0.0 priorities (especially for reviewers). I put my proposed "top 2-3" things that need to get in for each milestones here: https://github.com/bitcoindevkit/bdk/milestones. Happy to set up a quick chat next week to discuss if you want to do alpha releases differently.

Related to above I think #996 and #1028 should also move to alpha.2 or even alpha.3 milestones since they're really lower priority to get reviewed and merged than #1002 and #1023.

[LLFourn]

SGTM @notmandatory. Happy to see there's a strategy!

I mean taking that strategy I think this PR without even #1002 could be alpha.1 if alpha.2 will come shortly after (this would be handy since I am currently having to pin to certain git commits).

[notmandatory]

Once team agrees on priorities for each alpha.x milestone @nondiremanuel will help us manage which PRs get tagged to that milestone to be reviewed/merged first.

[notmandatory]

I'm holding off on the twitter and nostr announcements until we get to more stable beta releases.