Update DEVELOPMENT_CYCLE.md to work with [patch.crates-io]

Author: notmandatory

.github/ISSUE_TEMPLATE/release.md

@@ -0,0 +1,109 @@
+---
+name: Release
+about: Create a new release [for release managers only]
+title: 'Release MAJOR.MINOR.PATCH'
+labels: 'release'
+assignees: ''
+
+---
+
+Create a new release.
+
+**Summary**
+
+<--release summary to be used in announcements-->
+
+**Commit**
+
+<--latest commit ID to include in this release-->
+
+**Changelog**
+
+<--add notices from PRs merged since the prior release, see ["keep a changelog"]-->
+
+**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 for the current development **MAJOR.MINOR.0**
+release, 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` from `master`.
+- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
+  - The tag name should be `vMAJOR.MINOR.0-RC.1`
+  - Use message "Release MAJOR.MINOR.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.0-RC.1` tag.
+
+Change `master` branch version to next development **MAJOR.MINOR+1.0** release:
+
+- [ ] Switch back to the `master` branch.
+- [ ] Create a new PR branch called `bump_dev_MAJOR_MINOR+1`, eg. `bump_dev_0_18`.
+- [ ] Bump the `bump_dev_MAJOR_MINOR+1` branch to the next development MAJOR.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 dev version to MAJOR.MINOR+1.0".
+
+If any issues need to be fixed before the **MAJOR.MINOR.0** version is released:
+
+- [ ] Merge fix PRs to the `master` branch.
+- [ ] Git cherry-pick fix commits to the `release/MAJOR.MINOR` branch.
+- [ ] Verify fixes in `release/MAJOR.MINOR` branch.
+- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
+  - The tag name should be `vMAJOR.MINOR.0-RC.x+1`, where x is the current release candidate number.
+  - Use tag message "Release MAJOR.MINOR.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.0-RC.x+1` tag.
+
+On the day of a **MAJOR.MINOR.0** release:
+
+- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
+  - The tag name should be `vMAJOR.MINOR.0`
+  - The first line of the tag message should be "Release MAJOR.MINOR.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.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 :tada:
+
+On the day of a **MAJOR.MINOR.PATCH+1** release:
+
+- [ ] Merge fix PRs to the `master` branch.
+- [ ] Git cherry-pick fix commits to the `release/MAJOR.MINOR` branch to be patched.
+- [ ] Verify fixes in `release/MAJOR.MINOR` branch.
+- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
+  - The tag name should be `vMAJOR.MINOR.PATCH+1`
+  - The first line of the tag message should be "Release MAJOR.MINOR.PATCH+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 MAJOR.MINOR.PATCH+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 Mastodon.
+- [ ] Celebrate :tada:
+
+[Semantic Versioning]: https://semver.org/
+[crates.io]: https://crates.io/crates/bdk
+[docs.rs]: https://docs.rs/bdk/latest/bdk
+["keep a changelog"]: https://keepachangelog.com/en/1.0.0/

.github/pull_request_template.md

@@ -9,6 +9,11 @@
 <!-- In this section you can include notes directed to the reviewers, like explaining why some parts
 of the PR were done in a specific way -->
 
+### Changelog notice
+
+<!-- Notice the release manager should include in the release tag message changelog -->
+<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
+
 ### Checklists
 
 #### All Submissions:
@@ -21,7 +26,6 @@ of the PR were done in a specific way -->
 
 * [ ] I've added tests for the new feature
 * [ ] I've added docs for the new feature
-* [ ] I've updated `CHANGELOG.md`
 
 #### Bugfixes:
 

CHANGELOG.md

@@ -1,14 +1,12 @@
 # Changelog
-All notable changes to this project will be documented in this file.
+All notable changes to this project prior to release **0.22.0** are documented in this file. Future
+changelog information can be found in each release's git tag and can be viewed with `git tag -ln100 "v*"`.
+Changelog info is also documented on the [GitHub releases](https://github.com/bitcoindevkit/bdk/releases)
+page. See [DEVELOPMENT_CYCLE.md](DEVELOPMENT_CYCLE.md) for more details.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [Unreleased]
-- Add capacity to create FeeRate from sats/kvbytes and sats/kwu.
-- Rename `as_sat_vb` to `as_sat_per_vb`. Move all `FeeRate` test to `types.rs`.
-- Add custom Harware Wallet Signer `HwiSigner` in `src/wallet/harwaresigner/` module.
-
 ## [v0.21.0] - [v0.20.0]
 
 - Add `descriptor::checksum::get_checksum_bytes` method.
@@ -22,7 +20,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - New `RpcBlockchain` implementation with various fixes.
 - Return balance in separate categories, namely `confirmed`, `trusted_pending`, `untrusted_pending` & `immature`.
 
-
 ## [v0.20.0] - [v0.19.0]
 
 - New MSRV set to `1.56.1`
@@ -496,4 +493,3 @@ final transaction is created by calling `finish` on the builder.
 [v0.19.0]: https://github.com/bitcoindevkit/bdk/compare/v0.18.0...v0.19.0
 [v0.20.0]: https://github.com/bitcoindevkit/bdk/compare/v0.19.0...v0.20.0
 [v0.21.0]: https://github.com/bitcoindevkit/bdk/compare/v0.20.0...v0.21.0
-[unreleased]: https://github.com/bitcoindevkit/bdk/compare/v0.21.0...HEAD

DEVELOPMENT_CYCLE.md

@@ -1,46 +1,16 @@
 # Development Cycle
 
-This project follows a regular releasing schedule similar to the one [used by the Rust language](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). In short, this means that a new release is made at a regular cadence, with all the feature/bugfixes that made it to `master` in time. This ensures that we don't keep delaying releases waiting for "just one more little thing".
+This project follows a regular releasing schedule similar to the one [used by the Rust language]. In short, this means that a new release is made at a regular cadence, with all the feature/bugfixes that made it to `master` in time. This ensures that we don't keep delaying releases waiting for "just one more little thing".
+
+This project uses [Semantic Versioning], but is currently at MAJOR version zero (0.y.z) meaning it is still in initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. Until we reach version `1.0.0` we will do our best to document any breaking API changes in the changelog info attached to each release tag.
 
 We decided to maintain a faster release cycle while the library is still in "beta", i.e. before release `1.0.0`: since we are constantly adding new features and, even more importantly, fixing issues, we want developers to have access to those updates as fast as possible. For this reason we will make a release **every 4 weeks**.
 
-Once the project will have reached a more mature state (>= `1.0.0`), we will very likely switch to longer release cycles of **6 weeks**.
+Once the project reaches a more mature state (>= `1.0.0`), we will very likely switch to longer release cycles of **6 weeks**.
 
 The "feature freeze" will happen **one week before the release date**. This means a new branch will be created originating from the `master` tip at that time, and in that branch we will stop adding new features and only focus on ensuring the ones we've added are working properly.
 
-```
-master:           - - - - * - - - * - - - - - - * - - - * ...
-                          |      /              |       |
-release/0.x.0:            * - - #               |       |
-                                                |      /
-release/0.y.0:                                  * - - #
-```
-
-As soon as the release is tagged and published, the `release` branch will be merged back into `master` to update the version in the `Cargo.toml` to apply the new `Cargo.toml` version and all the other fixes made during the feature freeze window.
-
-## Making the Release
-
-What follows are notes and procedures that maintainers can refer to when making releases. All the commits and tags must be signed and, ideally, also [timestamped](https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md).
-
-Pre-`v1.0.0` our "major" releases only affect the "minor" semver value. Accordingly, our "minor" releases will only affect the "patch" value.
+To create a new release a release manager will create a new issue using the `Release` template and follow the template instructions.
 
-1. Create a new branch called `release/x.y.z` from `master`. Double check that your local `master` is up-to-date with the upstream repo before doing so.
-2. Make a commit on the release branch to bump the version to `x.y.z-rc.1`. The message should be "Bump version to x.y.z-rc.1".
-3. Push the new branch to `bitcoindevkit/bdk` on GitHub.
-4. During the one week of feature freeze run additional tests on the release branch.
-5. If a bug is found:
-    - If it's a minor issue you can just fix it in the release branch, since it will be merged back to `master` eventually
-    - For bigger issues you can fix them on `master` and then *cherry-pick* the commit to the release branch
-6. Update the changelog with the new release version.
-7. Update `src/lib.rs` with the new version (line ~43)
-8. On release day, make a commit on the release branch to bump the version to `x.y.z`. The message should be "Bump version to x.y.z".
-9. Add a tag to this commit. The tag name should be `vx.y.z` (for example `v0.5.0`), and the message "Release x.y.z". Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
-10. Push the new commits to the upstream release branch, wait for the CI to finish one last time.
-11. Publish **all** the updated crates to crates.io.
-12. Make a new commit to bump the version value to `x.y.(z+1)-dev`. The message should be "Bump version to x.y.(z+1)-dev".
-13. Merge the release branch back into `master`.
-14. If the `master` branch contains any unreleased changes to the `bdk-macros` crate, change the `bdk` Cargo.toml `[dependencies]` to point to the local path (i.e. `bdk-macros = { path = "./macros"}`)
-15. Create the release on GitHub: go to "tags", click on the dots on the right and select "Create Release". Then set the title to `vx.y.z` and write down some brief release notes.
-16. Make sure the new release shows up on crates.io and that the docs are built correctly on docs.rs.
-17. Announce the release on Twitter, Discord and Telegram.
-18. Celebrate :tada:
+[used by the Rust language]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
+[Semantic Versioning]: https://semver.org/

src/lib.rs

@@ -43,10 +43,6 @@
 //! blockchain data and an [electrum](https://docs.rs/electrum-client/) blockchain client to
 //! interact with the bitcoin P2P network.
 //!
-//! ```toml
-//! bdk = "0.21.0"
-//! ```
-//!
 //! # Examples
 #![cfg_attr(
     feature = "electrum",
@@ -81,6 +77,7 @@ fn main() -> Result<(), bdk::Error> {
 //!
 //! ## Generate a few addresses
 //!
+//! ### Example
 //! ```
 //! use bdk::{Wallet};
 //! use bdk::database::MemoryDatabase;