From fc1c58a2461b26b920785dba260dddd12a1aa755 Mon Sep 17 00:00:00 2001 From: mircea-c Date: Wed, 17 Apr 2019 13:02:06 -0400 Subject: [PATCH] Updated release process documentation (#4133) --- docs/RELEASE_PROCESS.md | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/docs/RELEASE_PROCESS.md b/docs/RELEASE_PROCESS.md index 3999025c2..bce2af93e 100644 --- a/docs/RELEASE_PROCESS.md +++ b/docs/RELEASE_PROCESS.md @@ -1,17 +1,13 @@ ### `cosmos/cosmos-sdk` Release Process -- [ ] 1. Decide on release designation (are we doing a patch, or minor version bump) and start a branch for the release -- [ ] 2. Add commits/PRs that are desired for this release **that haven’t already been added to develop** -- [ ] 3. Merge items in `PENDING.md` into the `CHANGELOG.md`. While doing this make sure that each entry contains links to issues/PRs for each item -- [ ] 4. Summarize breaking API changes section under “Breaking Changes” section to the `CHANGELOG.md` to bring attention to any breaking API changes that affect RPC consumers. -- [ ] 5. Tag the commit `git tag -a { .Release.Name }-rcN -m 'Release { .Release.Name }'` -- [ ] 6. Open PRs for both `master` and `develop`. From now onwards ***no additional PRs targeting develop should be merged**. Additional commits can be added on top of the release branch though. -- [ ] 7. Ensure both `master` and `develop` PRs ***pass tests***. -- [ ] 8. Kick off 1 day of automated fuzz testing -- [ ] 9. Release Lead assigns 2 people to perform [buddy testing script](/docs/RELEASE_TEST_SCRIPT.md) and update the relevant documentation -- [ ] 10. If errors are found in either #6 or #7 go back to #2 (*NOTE*: be sure to increment the `rcN`) -- [ ] 11. After #6 and #7 have successfully completed then merge the release PR create the final release annotated tag: - - `git tag -a -m { .Release.Name } 'Release { .Release.Name }' - - Merge **the release tag** to both `master` and `develop` so that both branches sit on top of the same commit: `branches='master develop' ; for b in $branches ; do git checkout $b ; git merge { .Release.Name } ; git push $b`. - Alternatively merge both the aforementioned release PRs. - - Push the final annotated release tag: `git push --tags` +Unless otherwise stated, all of the following tasks will be undertaken by the release manager/coordinator: + +- [ ] 1. Decide on release designation (are we doing a patch, or minor version bump) +- [ ] 2. Ensure that all commits/PRs which are destined for this release are merged to the `master` branch +- [ ] 3. Create the release candidate branch `rcN` (please start with `N=1`) (going forward known as **RC**) and ensure it's protected against pushing from anyone except the release manager/coordinator. **no PRs targeting this branch should be merged unless exceptional circumstances arise** +- [ ] 4. On the `RC` branch, use `clog` to prepare the `CHANGELOG.md`. +- [ ] 5. Summarize breaking API changes section under “Breaking Changes” section to the `CHANGELOG.md` to bring attention to any breaking API changes that affect RPC consumers. +- [ ] 6. Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks) +- [ ] 7. If errors are found in either #6 or #7 go back to #2 (*NOTE*: be sure to increment the `rcN`) +- [ ] 8. After #6 and #7 have successfully completed create the release branch from the `RC` branch (this will trigger the automated relase process which will build binaries, tag the release and push to github) +- [ ] 9. Merge the release branch to `master` and delete the `RC` branch