-
Notifications
You must be signed in to change notification settings - Fork 330
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Move release steps and checklist from DEVELOPMENT_CYCLE.md to a relea…
…se.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.
- Loading branch information
1 parent
7ee3a17
commit f20afc8
Showing
2 changed files
with
105 additions
and
82 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,26 +1,109 @@ | ||
| --- | ||
| name: Bug report | ||
| about: Create a report to help us improve | ||
| title: '' | ||
| labels: 'bug' | ||
| name: Release | ||
| about: Create a new release [for release managers only] | ||
| title: 'Release MAJOR.MINOR.PATCH' | ||
| labels: 'release' | ||
| assignees: '' | ||
|
|
||
| --- | ||
|
|
||
| **Describe the bug** | ||
| <!-- A clear and concise description of what the bug is. --> | ||
| Create a new release. | ||
|
|
||
| **To Reproduce** | ||
| <!-- Steps or code to reproduce the behavior. --> | ||
| **Summary** | ||
|
|
||
| **Expected behavior** | ||
| <!-- A clear and concise description of what you expected to happen. --> | ||
| <--release summary to be used in announcements--> | ||
|
|
||
| **Build environment** | ||
| - BDK tag/commit: <!-- e.g. v0.13.0, 3a07614 --> | ||
| - OS+version: <!-- e.g. ubuntu 20.04.01, macOS 12.0.1, windows --> | ||
| - Rust/Cargo version: <!-- e.g. 1.56.0 --> | ||
| - Rust/Cargo target: <!-- e.g. x86_64-apple-darwin, x86_64-unknown-linux-gnu, etc. --> | ||
| **Commit** | ||
|
|
||
| **Additional context** | ||
| <!-- Add any other context about the problem here. --> | ||
| <--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/ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,76 +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.md` file. | ||
| 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. | ||
|
|
||
| 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. | ||
|
|
||
| | Branch | | ||
|
|
||
|
|
||
| ``` | ||
| 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. | ||
|
|
||
| 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: | ||
|
|
||
| ### On x.y.0 release day or for x.y.z bug fix releases | ||
|
|
||
| 1. Add a tag to the `HEAD` commit in the `release/x.y` branch: | ||
| - The tag name should be `vx.y.z`, and the message "Release x.y.z". | ||
| - Make sure the tag is signed, for extra safety use the explicit `--sign` flag. | ||
| 1. Push the new tag to the upstream `release/x.y` branch, wait for the CI to finish one last time. | ||
| 1. Publish **all** the updated crates to crates.io. | ||
| 1. Merge the `release/x.y` branch CHANGELOG and any bug fixes back into `master`. | ||
| The version on `master` should stay `x.y+1.0`. | ||
| 1. 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"}`) | ||
| 1. Create the release on GitHub: | ||
| - Go to "tags", click on the dots on the right and select "Create Release". | ||
| - Set the title to `vx.y.z` and add a brief release description. | ||
| - Use the "+ Auto-generate release notes" button to add details from included PRs. | ||
| 1. Make sure the new release shows up on [crates.io] and that the docs are built correctly on [docs.rs]. | ||
| 1. Announce the release on Discord, Twitter and Mastodon. | ||
| 1. Celebrate :tada: | ||
| To create a new release a release manager will create a new issue using the `Release` template and follow the template instructions. | ||
|
|
||
| [used by the Rust language]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html | ||
| [Semantic Versioning]: https://semver.org/ | ||
| [crates.io]: https://crates.io/crates/bdk | ||
| [docs.rs]: https://docs.rs/bdk/latest/bdk |