Add a Release Process for SDK #1803
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,17 +1,17 @@ | ||
| <!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ | ||
| v ✰ Thanks for creating a PR! ✰ | ||
| v Before smashing the submit button please review the checkboxes. | ||
| v If a checkbox is n/a - please still include it but + a little note why | ||
| ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --> | ||
|
|
||
| - [ ] Linked to github-issue with discussion and accepted design | ||
| - [ ] Updated all relevant documentation (`docs/`) | ||
| - [ ] Updated all relevant code comments | ||
| - [ ] Wrote tests | ||
| - [ ] Added entries in `PENDING.md` that include links to the relevant issue or PR that most accurately describes the change. | ||
| - [ ] Updated `cmd/gaia` and `examples/` | ||
| ___________________________________ | ||
| For Admin Use: | ||
| - [ ] Added appropriate labels to PR (ex. wip, ready-for-review, docs) | ||
| - [ ] Reviewers Assigned | ||
| - [ ] Squashed all commits, uses message "Merge pull request #XYZ: [title]" ([coding standards](https://github.com/tendermint/coding/blob/master/README.md#merging-a-pr)) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| ### `cosmos/cosmos-sdk` Release Process | ||
|
|
||
| - [ ] 1. Decide on release designation (are we doing a patch, or minor version bump) and start a P.R. for the release | ||
| - [ ] 2. Add commits/PRs that are desired for this release **that haven’t already been added to develop** | ||
|
There was a problem hiding this comment. What might these be? Do you mean updating There was a problem hiding this comment. I don't know. This addition was at the request of @jaekwon There was a problem hiding this comment. @jaekwon can you clarify the above? ☝️ There was a problem hiding this comment. I think we want to keep this as optional for stuff like There was a problem hiding this comment. I'm thinking that we merge PRs into develop during our normal develop process, then when it comes time to release, we create a release meta-PR forked off of develop that further merges remaining PRs. Maybe this isn't what we should be doing? There was a problem hiding this comment. I guess I just don't understand what the "remaining PRs" would be - why would we merge a PR to a release branch if we hadn't already merged and tested it on develop? Did you have an example in mind? |
||
| - [ ] 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 `{{ .Release.Name }}-rcN` | ||
| - [ ] 6. Kick off 1 day of automated fuzz testing | ||
| - [ ] 7. Release Lead assigns 2 people to perform buddy testing script | ||
| - [ ] 8. If errors are found in either #6 or #7 go back to #2 (*NOTE*: be sure to increment the `rcN`) | ||
| - [ ] 9. After #6 and #7 have successfully completed then merge the release PR and push the final release tag | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we might need a different procedure for hotfixes (namely, we might want to backport a fix to an older release)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think
hotfixis a usecase we didn't solve for with this process.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a hotfix procedure which may be (I hope 🤞) be out of scope for this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a hotfix release should in scope cause we need to differentiate what parts of the checklist we keep.
Hotfixes should have less testing before they go out.
We don't need to several days of internal testnets.
We do need to fire a testnet and run some transactions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're about to do a hotfix tomorrow (as per @cwgoes comment about cherry-picking 2 commits for 0.23) so lets figure it out tomorrow.