Skip to content

Commit cf13c80

Browse files
afiliniafilini
committed
Merge #544: Update DEVELOPMENT_CYCLE.md to work with [patch.crates-io]
7c57965 Bump version before making release branch, separate patch_release template (Steve Myers) 3d69f1c Update DEVELOPMENT_CYCLE.md to work with [patch.crates-io] (Steve Myers) Pull request description: ### Description Update DEVELOPMENT_CYCLE and release instructions to make [overriding dependencies] possible for downstream projects with unreleased `bdk` versions for development and testing. Also simplifies the release process by capturing changelog information in the `pull_request_template` and recording release changelog information in the release tag message instead of in a `CHANGELOG.md` file which causes too many merge conflicts and complicates the release process. Fixes #536 Fixes #496 ### Notes to the reviewers The primary changes to our current release process are: 1. Don't add `-dev` or `-rc.x` to unreleased `bdk` cargo versions because those extensions do not work with [overriding dependencies]. 2. Increment the `master` branch version as soon as a `release/MAJOR.MINOR` branch is created, the next release `release/MAJOR.MINOR` branch version with be **MAJOR.MINOR.PATCH**, and the `master` branch development version will be **MAJOR.MINOR+1.0**; either version can be used with [overriding dependencies]. 4. Remove the `bdk` version from the `src/lib.rs` file so that it doesn't need to be changed on every release, because it isn't needed in the rust docs for most developers and removing it will help simplify the release process. 5. The new release process is now documented as a checklist in a new `release.md` github issue template. 6. Putting changelog information in the release tag message is how the tokio project does it. ~~After this PR is merged I will replace old tags with new ones containing changelog information and then do a new PR to remove the CHANGELOG.md file.~~ After this PR is merged I don't think we need to update old tags, only rename the CHANGELOG.md file to CHANGELOG-OLD.md with a note to check tags for future change log info. [overriding dependencies]: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html ### Checklists #### All Submissions: * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) * [x] I ran `cargo fmt` and `cargo clippy` before committing ACKs for top commit: afilini: ACK 7c57965 Tree-SHA512: 818e2f9bc7a629cbbb190a83b9743e8f4de49a4093beae83ed0b9c506f33e6f96b2c1e376f788536d58c46908d278bde08140f43a625515401ea1f9efdb9153f
2 parents 4fbd852 + 7c57965 commit cf13c80

File tree

7 files changed

+174
-51
lines changed

7 files changed

+174
-51
lines changed

‎.github/ISSUE_TEMPLATE/minor_release.md

+89
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
---
2+
name: Minor Release
3+
about: Create a new minor release [for release managers only]
4+
title: 'Release MAJOR.MINOR+1.0'
5+
labels: 'release'
6+
assignees: ''
7+
8+
---
9+
10+
## Create a new minor release
11+
12+
### Summary
13+
14+
<--release summary to be used in announcements-->
15+
16+
### Commit
17+
18+
<--latest commit ID to include in this release-->
19+
20+
### Changelog
21+
22+
<--add notices from PRs merged since the prior release, see ["keep a changelog"]-->
23+
24+
### Checklist
25+
26+
Release numbering must follow [Semantic Versioning]. These steps assume the current `master`
27+
branch **development** version is *MAJOR.MINOR.0*.
28+
29+
#### On the day of the feature freeze
30+
31+
Change the `master` branch to the next MINOR+1 version:
32+
33+
- [ ] Switch to the `master` branch.
34+
- [ ] Create a new PR branch called `bump_dev_MAJOR_MINOR+1`, eg. `bump_dev_0_22`.
35+
- [ ] Bump the `bump_dev_MAJOR_MINOR+1` branch to the next development MINOR+1 version.
36+
- Change the `Cargo.toml` version value to `MAJOR.MINOR+1.0`.
37+
- The commit message should be "Bump version to MAJOR.MINOR+1.0".
38+
- [ ] Create PR and merge the `bump_dev_MAJOR_MINOR+1` branch to `master`.
39+
- Title PR "Bump version to MAJOR.MINOR+1.0".
40+
41+
Create a new release branch and release candidate tag:
42+
43+
- [ ] Double check that your local `master` is up-to-date with the upstream repo.
44+
- [ ] Create a new branch called `release/MAJOR.MINOR+1` from `master`.
45+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR+1` branch.
46+
- The tag name should be `vMAJOR.MINOR+1.0-RC.1`
47+
- Use message "Release MAJOR.MINOR+1.0 RC.1".
48+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
49+
- [ ] Push the `release/MAJOR.MINOR` branch and new tag to the `bitcoindevkit/bdk` repo.
50+
- Use `git push --tags` option to push the new `vMAJOR.MINOR+1.0-RC.1` tag.
51+
52+
If any issues need to be fixed before the *MAJOR.MINOR+1.0* version is released:
53+
54+
- [ ] Merge fix PRs to the `master` branch.
55+
- [ ] Git cherry-pick fix commits to the `release/MAJOR.MINOR+1` branch.
56+
- [ ] Verify fixes in `release/MAJOR.MINOR+1` branch.
57+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR+1` branch.
58+
- The tag name should be `vMAJOR.MINOR+1.0-RC.x+1`, where x is the current release candidate number.
59+
- Use tag message "Release MAJOR.MINOR+1.0 RC.x+1".
60+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
61+
- [ ] Push the new tag to the `bitcoindevkit/bdk` repo.
62+
- Use `git push --tags` option to push the new `vMAJOR.MINOR+1.0-RC.x+1` tag.
63+
64+
#### On the day of the release
65+
66+
Tag and publish new release:
67+
68+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR+1` branch.
69+
- The tag name should be `vMAJOR.MINOR+1.0`
70+
- The first line of the tag message should be "Release MAJOR.MINOR+1.0".
71+
- In the body of the tag message put a copy of the **Summary** and **Changelog** for the release.
72+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
73+
- [ ] Wait for the CI to finish one last time.
74+
- [ ] Push the new tag to the `bitcoindevkit/bdk` repo.
75+
- [ ] Publish **all** the updated crates to crates.io.
76+
- [ ] Create the release on GitHub.
77+
- Go to "tags", click on the dots on the right and select "Create Release".
78+
- Set the title to `Release MAJOR.MINOR+1.0`.
79+
- In the release notes body put the **Summary** and **Changelog**.
80+
- Use the "+ Auto-generate release notes" button to add details from included PRs.
81+
- Until we reach a `1.0.0` release check the "Pre-release" box.
82+
- [ ] Make sure the new release shows up on [crates.io] and that the docs are built correctly on [docs.rs].
83+
- [ ] Announce the release, using the **Summary**, on Discord, Twitter and Mastodon.
84+
- [ ] Celebrate 🎉
85+
86+
[Semantic Versioning]: https://semver.org/
87+
[crates.io]: https://crates.io/crates/bdk
88+
[docs.rs]: https://docs.rs/bdk/latest/bdk
89+
["keep a changelog"]: https://keepachangelog.com/en/1.0.0/

‎.github/ISSUE_TEMPLATE/patch_release.md

+67
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
---
2+
name: Patch Release
3+
about: Create a new patch release [for release managers only]
4+
title: 'Release MAJOR.MINOR.PATCH+1'
5+
labels: 'release'
6+
assignees: ''
7+
8+
---
9+
10+
## Create a new patch release
11+
12+
### Summary
13+
14+
<--release summary to be used in announcements-->
15+
16+
### Commit
17+
18+
<--latest commit ID to include in this release-->
19+
20+
### Changelog
21+
22+
<--add notices from PRs merged since the prior release, see ["keep a changelog"]-->
23+
24+
### Checklist
25+
26+
Release numbering must follow [Semantic Versioning]. These steps assume the current `master`
27+
branch **development** version is *MAJOR.MINOR.PATCH*.
28+
29+
### On the day of the patch release
30+
31+
Change the `master` branch to the new PATCH+1 version:
32+
33+
- [ ] Switch to the `master` branch.
34+
- [ ] Create a new PR branch called `bump_dev_MAJOR_MINOR_PATCH+1`, eg. `bump_dev_0_22_1`.
35+
- [ ] Bump the `bump_dev_MAJOR_MINOR` branch to the next development PATCH+1 version.
36+
- Change the `Cargo.toml` version value to `MAJOR.MINOR.PATCH+1`.
37+
- The commit message should be "Bump version to MAJOR.MINOR.PATCH+1".
38+
- [ ] Create PR and merge the `bump_dev_MAJOR_MINOR_PATCH+1` branch to `master`.
39+
- Title PR "Bump version to MAJOR.MINOR.PATCH+1".
40+
41+
Cherry-pick, tag and publish new PATCH+1 release:
42+
43+
- [ ] Merge fix PRs to the `master` branch.
44+
- [ ] Git cherry-pick fix commits to the `release/MAJOR.MINOR` branch to be patched.
45+
- [ ] Verify fixes in `release/MAJOR.MINOR` branch.
46+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
47+
- The tag name should be `vMAJOR.MINOR.PATCH+1`
48+
- The first line of the tag message should be "Release MAJOR.MINOR.PATCH+1".
49+
- In the body of the tag message put a copy of the **Summary** and **Changelog** for the release.
50+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
51+
- [ ] Wait for the CI to finish one last time.
52+
- [ ] Push the new tag to the `bitcoindevkit/bdk` repo.
53+
- [ ] Publish **all** the updated crates to crates.io.
54+
- [ ] Create the release on GitHub.
55+
- Go to "tags", click on the dots on the right and select "Create Release".
56+
- Set the title to `Release MAJOR.MINOR.PATCH+1`.
57+
- In the release notes body put the **Summary** and **Changelog**.
58+
- Use the "+ Auto-generate release notes" button to add details from included PRs.
59+
- Until we reach a `1.0.0` release check the "Pre-release" box.
60+
- [ ] Make sure the new release shows up on [crates.io] and that the docs are built correctly on [docs.rs].
61+
- [ ] Announce the release, using the **Summary**, on Discord, Twitter and Mastodon.
62+
- [ ] Celebrate 🎉
63+
64+
[Semantic Versioning]: https://semver.org/
65+
[crates.io]: https://crates.io/crates/bdk
66+
[docs.rs]: https://docs.rs/bdk/latest/bdk
67+
["keep a changelog"]: https://keepachangelog.com/en/1.0.0/

‎.github/pull_request_template.md

+5-1
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,11 @@
99
<!-- In this section you can include notes directed to the reviewers, like explaining why some parts
1010
of the PR were done in a specific way -->
1111

12+
### Changelog notice
13+
14+
<!-- Notice the release manager should include in the release tag message changelog -->
15+
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
16+
1217
### Checklists
1318

1419
#### All Submissions:
@@ -21,7 +26,6 @@ of the PR were done in a specific way -->
2126

2227
* [ ] I've added tests for the new feature
2328
* [ ] I've added docs for the new feature
24-
* [ ] I've updated `CHANGELOG.md`
2529

2630
#### Bugfixes:
2731

‎CHANGELOG.md

+4-8
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,12 @@
11
# Changelog
2-
All notable changes to this project will be documented in this file.
2+
All notable changes to this project prior to release **0.22.0** are documented in this file. Future
3+
changelog information can be found in each release's git tag and can be viewed with `git tag -ln100 "v*"`.
4+
Changelog info is also documented on the [GitHub releases](https://github.com/bitcoindevkit/bdk/releases)
5+
page. See [DEVELOPMENT_CYCLE.md](DEVELOPMENT_CYCLE.md) for more details.
36

47
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
58
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
69

7-
## [Unreleased]
8-
- Add capacity to create FeeRate from sats/kvbytes and sats/kwu.
9-
- Rename `as_sat_vb` to `as_sat_per_vb`. Move all `FeeRate` test to `types.rs`.
10-
- Add custom Harware Wallet Signer `HwiSigner` in `src/wallet/harwaresigner/` module.
11-
- Add `allow_dust` method on `TxBuilder`.
12-
1310
## [v0.21.0] - [v0.20.0]
1411

1512
- Add `descriptor::checksum::get_checksum_bytes` method.
@@ -496,4 +493,3 @@ final transaction is created by calling `finish` on the builder.
496493
[v0.19.0]: https://github.com/bitcoindevkit/bdk/compare/v0.18.0...v0.19.0
497494
[v0.20.0]: https://github.com/bitcoindevkit/bdk/compare/v0.19.0...v0.20.0
498495
[v0.21.0]: https://github.com/bitcoindevkit/bdk/compare/v0.20.0...v0.21.0
499-
[unreleased]: https://github.com/bitcoindevkit/bdk/compare/v0.21.0...HEAD

‎Cargo.toml

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
[package]
22
name = "bdk"
3-
version = "0.21.1-dev"
3+
version = "0.21.0"
44
edition = "2018"
55
authors = ["Alekos Filini <[email protected]>", "Riccardo Casatta <[email protected]>"]
66
homepage = "https://bitcoindevkit.org"

‎DEVELOPMENT_CYCLE.md

+7-37
Original file line numberDiff line numberDiff line change
@@ -1,46 +1,16 @@
11
# Development Cycle
22

3-
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".
3+
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".
4+
5+
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.
46

57
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**.
68

7-
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**.
9+
Once the project reaches a more mature state (>= `1.0.0`), we will very likely switch to longer release cycles of **6 weeks**.
810

911
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.
1012

11-
```
12-
master: - - - - * - - - * - - - - - - * - - - * ...
13-
| / | |
14-
release/0.x.0: * - - # | |
15-
| /
16-
release/0.y.0: * - - #
17-
```
18-
19-
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.
20-
21-
## Making the Release
22-
23-
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).
24-
25-
Pre-`v1.0.0` our "major" releases only affect the "minor" semver value. Accordingly, our "minor" releases will only affect the "patch" value.
13+
To create a new release a release manager will create a new issue using the `Release` template and follow the template instructions.
2614

27-
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.
28-
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".
29-
3. Push the new branch to `bitcoindevkit/bdk` on GitHub.
30-
4. During the one week of feature freeze run additional tests on the release branch.
31-
5. If a bug is found:
32-
- If it's a minor issue you can just fix it in the release branch, since it will be merged back to `master` eventually
33-
- For bigger issues you can fix them on `master` and then *cherry-pick* the commit to the release branch
34-
6. Update the changelog with the new release version.
35-
7. Update `src/lib.rs` with the new version (line ~43)
36-
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".
37-
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.
38-
10. Push the new commits to the upstream release branch, wait for the CI to finish one last time.
39-
11. Publish **all** the updated crates to crates.io.
40-
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".
41-
13. Merge the release branch back into `master`.
42-
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"}`)
43-
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.
44-
16. Make sure the new release shows up on crates.io and that the docs are built correctly on docs.rs.
45-
17. Announce the release on Twitter, Discord and Telegram.
46-
18. Celebrate :tada:
15+
[used by the Rust language]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
16+
[Semantic Versioning]: https://semver.org/

‎src/lib.rs

+1-4
Original file line numberDiff line numberDiff line change
@@ -43,10 +43,6 @@
4343
//! blockchain data and an [electrum](https://docs.rs/electrum-client/) blockchain client to
4444
//! interact with the bitcoin P2P network.
4545
//!
46-
//! ```toml
47-
//! bdk = "0.21.0"
48-
//! ```
49-
//!
5046
//! # Examples
5147
#![cfg_attr(
5248
feature = "electrum",
@@ -81,6 +77,7 @@ fn main() -> Result<(), bdk::Error> {
8177
//!
8278
//! ## Generate a few addresses
8379
//!
80+
//! ### Example
8481
//! ```
8582
//! use bdk::{Wallet};
8683
//! use bdk::database::MemoryDatabase;

0 commit comments

Comments
 (0)