Skip to content

Commit 98ad84d

Browse files
notmandatorynotmandatory
committed
Move release steps and checklist from DEVELOPMENT_CYCLE.md to a release.md issue template
Also change release process to use the tag message for changelog information and to keep master branch on the version of the next MAJOR.MINOR release.
1 parent f36c3e8 commit 98ad84d

File tree

2 files changed

+105
-82
lines changed

2 files changed

+105
-82
lines changed

‎.github/ISSUE_TEMPLATE/release.md

+100-17
Original file line numberDiff line numberDiff line change
@@ -1,26 +1,109 @@
11
---
2-
name: Bug report
3-
about: Create a report to help us improve
4-
title: ''
5-
labels: 'bug'
2+
name: Release
3+
about: Create a new release [for release managers only]
4+
title: 'Release MAJOR.MINOR.PATCH'
5+
labels: 'release'
66
assignees: ''
77

88
---
99

10-
**Describe the bug**
11-
<!-- A clear and concise description of what the bug is. -->
10+
Create a new release.
1211

13-
**To Reproduce**
14-
<!-- Steps or code to reproduce the behavior. -->
12+
**Summary**
1513

16-
**Expected behavior**
17-
<!-- A clear and concise description of what you expected to happen. -->
14+
<--release summary to be used in announcements-->
1815

19-
**Build environment**
20-
- BDK tag/commit: <!-- e.g. v0.13.0, 3a07614 -->
21-
- OS+version: <!-- e.g. ubuntu 20.04.01, macOS 12.0.1, windows -->
22-
- Rust/Cargo version: <!-- e.g. 1.56.0 -->
23-
- Rust/Cargo target: <!-- e.g. x86_64-apple-darwin, x86_64-unknown-linux-gnu, etc. -->
16+
**Commit**
2417

25-
**Additional context**
26-
<!-- Add any other context about the problem here. -->
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
27+
current `master` branch **development** version is **MAJOR.MINOR.0**.
28+
29+
On the day of the feature freeze for the current development **MAJOR.MINOR.0**
30+
release create a new release branch and release candidate tag:
31+
32+
- [ ] Double check that your local `master` is up-to-date with the upstream repo.
33+
- [ ] Create a new branch called `release/MAJOR.MINOR` from `master`.
34+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
35+
- The tag name should be `vMAJOR.MINOR.0-RC.1`
36+
- Use message "Release MAJOR.MINOR.0 RC.1".
37+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
38+
- [ ] Push the `release/MAJOR.MINOR` branch and new tag to the `bitcoindevkit/bdk` repo.
39+
- Use `git push --tags` option to push the new `vMAJOR.MINOR.0-RC.1` tag.
40+
41+
Change `master` branch version to next development **MAJOR.MINOR+1.0** release:
42+
43+
- [ ] Switch back to the `master` branch.
44+
- [ ] Create a new PR branch called `bump_dev_MAJOR_MINOR+1`, eg. `bump_dev_0_18`.
45+
- [ ] Bump the `bump_dev_MAJOR_MINOR+1` branch to the next development MAJOR.MINOR+1 version.
46+
- Change the `Cargo.toml` version value to `MAJOR.MINOR+1.0`.
47+
- The commit message should be "Bump version to MAJOR.MINOR+1.0".
48+
- [ ] Create PR and merge the `bump_dev_MAJOR_MINOR+1` branch to `master`.
49+
- Title PR "Bump dev version to MAJOR.MINOR+1.0".
50+
51+
If any issues need to be fixed before the **MAJOR.MINOR.0** version is released:
52+
53+
- [ ] Merge fix PRs to the `master` branch.
54+
- [ ] Git cherry-pick fix commits to the `release/MAJOR.MINOR` branch.
55+
- [ ] Verify fixes in `release/MAJOR.MINOR` branch.
56+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
57+
- The tag name should be `vMAJOR.MINOR.0-RC.x+1`, where x is the current release candidate number.
58+
- Use tag message "Release MAJOR.MINOR.0 RC.x+1".
59+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
60+
- [ ] Push the new tag to the `bitcoindevkit/bdk` repo.
61+
- Use `git push --tags` option to push the new `vMAJOR.MINOR.0-RC.x+1` tag.
62+
63+
On the day of a **MAJOR.MINOR.0** release:
64+
65+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
66+
- The tag name should be `vMAJOR.MINOR.0`
67+
- The first line of the tag message should be "Release MAJOR.MINOR.0".
68+
- In the body of the tag message put a copy of the **Summary** and **Changelog** for the release.
69+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
70+
- [ ] Wait for the CI to finish one last time.
71+
- [ ] Push the new tag to the `bitcoindevkit/bdk` repo.
72+
- [ ] Publish **all** the updated crates to crates.io.
73+
- [ ] Create the release on GitHub.
74+
- Go to "tags", click on the dots on the right and select "Create Release".
75+
- Set the title to `Release MAJOR.MINOR.0`.
76+
- In the release notes body put the **Summary** and **Changelog**.
77+
- Use the "+ Auto-generate release notes" button to add details from included PRs.
78+
- Until we reach a `1.0.0` release check the "Pre-release" box.
79+
- [ ] Make sure the new release shows up on [crates.io] and that the docs are built correctly on [docs.rs].
80+
- [ ] Announce the release, using the **Summary**, on Discord, Twitter and Mastodon.
81+
- [ ] Celebrate :tada:
82+
83+
On the day of a **MAJOR.MINOR.PATCH+1** release:
84+
85+
- [ ] Merge fix PRs to the `master` branch.
86+
- [ ] Git cherry-pick fix commits to the `release/MAJOR.MINOR` branch to be patched.
87+
- [ ] Verify fixes in `release/MAJOR.MINOR` branch.
88+
- [ ] Add a tag to the `HEAD` commit in the `release/MAJOR.MINOR` branch.
89+
- The tag name should be `vMAJOR.MINOR.PATCH+1`
90+
- The first line of the tag message should be "Release MAJOR.MINOR.PATCH+1".
91+
- In the body of the tag message put a copy of the **Summary** and **Changelog** for the release.
92+
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
93+
- [ ] Wait for the CI to finish one last time.
94+
- [ ] Push the new tag to the `bitcoindevkit/bdk` repo.
95+
- [ ] Publish **all** the updated crates to crates.io.
96+
- [ ] Create the release on GitHub.
97+
- Go to "tags", click on the dots on the right and select "Create Release".
98+
- Set the title to `Release MAJOR.MINOR.PATCH+1`.
99+
- In the release notes body put the **Summary** and **Changelog**.
100+
- Use the "+ Auto-generate release notes" button to add details from included PRs.
101+
- Until we reach a `1.0.0` release check the "Pre-release" box.
102+
- [ ] Make sure the new release shows up on [crates.io] and that the docs are built correctly on [docs.rs].
103+
- [ ] Announce the release, using the **Summary**, on Discord, Twitter and Mastodon.
104+
- [ ] Celebrate :tada:
105+
106+
[Semantic Versioning]: https://semver.org/
107+
[crates.io]: https://crates.io/crates/bdk
108+
[docs.rs]: https://docs.rs/bdk/latest/bdk
109+
["keep a changelog"]: https://keepachangelog.com/en/1.0.0/

‎DEVELOPMENT_CYCLE.md

+5-65
Original file line numberDiff line numberDiff line change
@@ -1,76 +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".
44

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.md` file.
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.
66

77
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**.
88

9-
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**.
1010

1111
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.
1212

13-
If a bug is found that can not wait for the next schedule release it will first be reviewed and merged to the master branch and then cherry-picked to the current release branch. Once tested and verified on the release branch a new patch release will be made from that branch.
14-
15-
| Branch |
16-
17-
18-
```
19-
master: - - - - * - - - * - - - - - - * - - - * ...
20-
| / | |
21-
release/0.x.0: * - - # | |
22-
| /
23-
release/0.y.0: * - - #
24-
```
25-
26-
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.
27-
28-
## Making the Release
29-
30-
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).
31-
32-
Pre-`v1.0.0` our "major" releases only affect the "minor" semver value. Accordingly, our "minor" releases will only affect the "patch" value.
33-
34-
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.
35-
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".
36-
3. Push the new branch to `bitcoindevkit/bdk` on GitHub.
37-
4. During the one week of feature freeze run additional tests on the release branch.
38-
5. If a bug is found:
39-
- If it's a minor issue you can just fix it in the release branch, since it will be merged back to `master` eventually
40-
- For bigger issues you can fix them on `master` and then *cherry-pick* the commit to the release branch
41-
6. Update the changelog with the new release version.
42-
7. Update `src/lib.rs` with the new version (line ~43)
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".
44-
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.
45-
10. Push the new commits to the upstream release branch, wait for the CI to finish one last time.
46-
11. Publish **all** the updated crates to crates.io.
47-
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".
48-
13. Merge the release branch back into `master`.
49-
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 (ie. `bdk-macros = { path = "./macros"}`)
50-
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.
51-
16. Make sure the new release shows up on crates.io and that the docs are built correctly on docs.rs.
52-
17. Announce the release on Twitter, Discord and Telegram.
53-
18. Celebrate :tada:
54-
55-
### On x.y.0 release day or for x.y.z bug fix releases
56-
57-
1. Add a tag to the `HEAD` commit in the `release/x.y` branch:
58-
- The tag name should be `vx.y.z`, and the message "Release x.y.z".
59-
- Make sure the tag is signed, for extra safety use the explicit `--sign` flag.
60-
1. Push the new tag to the upstream `release/x.y` branch, wait for the CI to finish one last time.
61-
1. Publish **all** the updated crates to crates.io.
62-
1. Merge the `release/x.y` branch CHANGELOG and any bug fixes back into `master`.
63-
The version on `master` should stay `x.y+1.0`.
64-
1. If the `master` branch contains any unreleased changes to the `bdk-macros` crate, change the
65-
`bdk` Cargo.toml `[dependencies]` to point to the local path (ie. `bdk-macros = { path = "./macros"}`)
66-
1. Create the release on GitHub:
67-
- Go to "tags", click on the dots on the right and select "Create Release".
68-
- Set the title to `vx.y.z` and add a brief release description.
69-
- Use the "+ Auto-generate release notes" button to add details from included PRs.
70-
1. Make sure the new release shows up on [crates.io] and that the docs are built correctly on [docs.rs].
71-
1. Announce the release on Discord, Twitter and Mastodon.
72-
1. Celebrate :tada:
13+
To create a new release a release manager will create a new issue using the `Release` template and follow the template instructions.
7314

15+
[used by the Rust language]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
7416
[Semantic Versioning]: https://semver.org/
75-
[crates.io]: https://crates.io/crates/bdk
76-
[docs.rs]: https://docs.rs/bdk/latest/bdk

0 commit comments

Comments
 (0)