Conversation
Codecov Report
@@ Coverage Diff @@
## develop #3503 +/- ##
==========================================
+ Coverage 64.22% 64.4% +0.18%
==========================================
Files 213 213
Lines 17503 17459 -44
==========================================
+ Hits 11241 11245 +4
+ Misses 5320 5274 -46
+ Partials 942 940 -2
|
|
|
||
| Note all pull requests should be squash merged except for merging to master and | ||
| merging master back to develop. This keeps the commit history clean and makes it | ||
| easy to reference the pull request where a change was introduced. |
There was a problem hiding this comment.
What if we want to include a PR that made it into develop after the release branch has been created? Squashing those changes will create another commit for the same changes. For example see: #3491
If we squash merge this, it will create a commit that will make it to the release branch and then to master. The same changes exist under develop with a different commit.
There was a problem hiding this comment.
Can we enforce this through branch protection in github settings?
There was a problem hiding this comment.
Merging develop to release branch should be done with a normal merge, not squash. You're correct here.
Ideally we minimize this. In the ideal case, the release branch is checked out directly from develop and merged to master with no more changes.
I suppose this means we should continue to do all review and finalization on develop before we make the release branch, so that ideally there's no PRs against only the release branch.
But that would cause develop to freeze while we're prepping the release, which isn't ideal, so there's some tension here.
I don't think it's a big deal to have some merges from develop into release. But we can also just retarget PRs to the release branch to minimize the number of times we have new stuff on develop that we want in the release after we've already made the release branch ...
There was a problem hiding this comment.
Can we enforce this through branch protection in github settings?
Which part?
I don't think we can enforce the squash merge rules :(
| - merge master back to develop | ||
| - bump versions | ||
| - push latest develop with prepared release details to release/vX.X.X to run the extended integration tests on the CI | ||
| - if necessary, make pull requests against release/vX.X.X and squash merge them |
There was a problem hiding this comment.
see: https://github.com/tendermint/tendermint/pull/3503/files#r269982992
There are edge cases where we do want to merge instead of squash (we can either disallow these cases or use merge).
There was a problem hiding this comment.
this should say "new pull requests, based on the release branch, against the release branch".
The only case we don't want to squash merge (afaik) is when we need to merge develop to the release branch. But in general we should be able to avoid that by basing those fixes on the release branch in the first place, yeh ?
There was a problem hiding this comment.
in general we should be able to avoid that by basing those fixes on the release branch in the first place, yeh ?
Yes, makes sense. We should base PRs directly on the release branch if we are sure, we want to include them.
xla
left a comment
There was a problem hiding this comment.
🐙 
Should we mention how we see versions to be bumped in the context of this document?
|
|
||
| Note all pull requests should be squash merged except for merging to master and | ||
| merging master back to develop. This keeps the commit history clean and makes it | ||
| easy to reference the pull request where a change was introduced. |
There was a problem hiding this comment.
Can we enforce this through branch protection in github settings?
|
Need to also specify changelog entry title for changes that affect top level stuff like docker, circle, etc. #3512 (comment) |
Minor updates to reflect squash merging and how to prepare releases
Minor updates to reflect squash merging and how to prepare releases