LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

Revise Point Release Process (#6333)

Browse Source 
* Update point release process

* Update CONTRIBUTING.md

Co-authored-by: Alessio Treglia <alessio@tendermint.com>

Co-authored-by: Alessio Treglia <alessio@tendermint.com>
This commit is contained in:
Alexander Bezobchuk 2020-06-03 11:16:40 -04:00 committed by GitHub
parent 8d12c948b2
commit d17f5771c7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 34 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
CONTRIBUTING.md
View File

@ -7,6 +7,7 @@
- [Updating Documentation](#updating-documentation)
- [Forking](#forking)
- [Dependencies](#dependencies)
- [Protobuf](#protobuf)
- [Testing](#testing)
- [Branching Model and Release](#branching-model-and-release)
- [PR Targeting](#pr-targeting)
@ -14,6 +15,7 @@
- [Pull Merge Procedure](#pull-merge-procedure)
- [Release Procedure](#release-procedure)
- [Point Release Procedure](#point-release-procedure)
- [Code Owner Membership](#code-owner-membership)
Thank you for considering making contributions to Cosmos-SDK and related
repositories!
@ -228,23 +230,39 @@ only pull requests targeted directly against master.
### Point Release Procedure
At the moment, only a single major release will be supported, so all point
releases will be based off of that release.
At the moment, only a single major release will be supported, so all point releases will be based
off of that release.
- start on `vX.XX.X`
- checkout a new branch `rcN/vX.X.X`
- cherry pick the desired changes from `master`
- these changes should be small and NON-BREAKING (both API and state machine)
- create a `RELEASE_CHANGELOG.md`, add entires.
- this is needed so the bot knows which entries to add to the release page on github.
- checkout a new branch `release/vX.X.X` based off of the previous release
- create a PR merging `rcN/vX.X.X` into `release/vX.X.X`
- run tests and simulations (noted in [Release Procedure](#release-procedure))
- after tests and simulation have successfully completed, merge the `RC` branch into `release/vX.X.X`
- Make sure to delete the `RC` branch
- create a PR into `master` containing ONLY CHANGELOG.md updates
- Do not push `RELEASE_CHANGELOG.md` to master
- tag (use `git tag -a`) then push the tags (`git push --tags`)
In order to alleviate the burden for a single person to have to cherry-pick and handle merge conflicts
of all desired backporting PRs to a point release, we instead maintain a living backport branch, where
all desired features and bug fixes are merged into as separate PRs.
Example:
Current release is `v0.38.4`. We then maintain a (living) branch `backport/release/v0.38.x`. As PRs
are merged into master, if they wish to be backported into the next `v0.38.x` point release, the
author must:
1. Add `backport` label
2. Pull latest changes on the desired `backport/release/v*.*.x` branch
3. Create a 2nd PR merging the respective backport PR into `backport/release/v*.*.x`
This means it is the authors responsibility to fix any merge conflicts, update changelog entries, and
ensure CI passes. If a PR originates from an external contributor, it may be a team members responsibility
to perform this process instead of the original author.
Finally, when a point release is ready to be made:
1. Create `release/v*.*.x` branch
2. Ensure changelog entries are verified
2. Be sure changelog entries are added to `RELEASE_CHANGELOG.md`
3. Add release version date to the changelog
4. Push release branch along with the annotated tag: **git tag -a**
5. Create a PR into `master` containing ONLY `CHANGELOG.md` updates
1. Do not push `RELEASE_CHANGELOG.md` to `master`
Note, although we aim to support only a single release at a time, the process stated above could be
used for multiple previous versions.
## Code Owner Membership