From c68716481b5f291f5feb26d886839e1567d9c689 Mon Sep 17 00:00:00 2001 From: Alekos Filini Date: Fri, 18 Dec 2020 12:08:54 +0100 Subject: [PATCH] Document the development cycle --- DEVELOPMENT_CYCLE.md | 46 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 DEVELOPMENT_CYCLE.md diff --git a/DEVELOPMENT_CYCLE.md b/DEVELOPMENT_CYCLE.md new file mode 100644 index 00000000..0f05846d --- /dev/null +++ b/DEVELOPMENT_CYCLE.md @@ -0,0 +1,46 @@ +# 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". + +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**. + +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 maintaners 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. 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". +7. 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. +8. Push the new commits to the upstream release branch, wait for the CI to finish one last time. +9. Publish **all** the updated crates to crates.io. +10. 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". +11. Merge the release branch back into `master`. +12. Make sure the new release shows up on crates.io and that the docs are built correctly on docs.rs. +13. Announce the release on Twitter, Discord and Telegram. +14. Celebrate :tada: