Moar release docs #9153
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| # Expected git graph | ||
|
|
||
|  | ||
|
|
||
| ## Continued branches | ||
|
|
||
| - *master* this is development branch | ||
| - *release* this branch list all the release commits | ||
| It's important that `git show release~$X` shows version releases first. | ||
|
|
||
| ## Creating this graph: | ||
|
There was a problem hiding this comment. What's the relationship of this document to docs/RELEASE_ISSUE_TEMPLATE.md ? I don't see any crosslinking. Why isn't this info inlined into the release issue template? I think it would be helpful to state what the purpose of this document is with a "Purpose" section. There was a problem hiding this comment. I haven't compared in detail but at least some of the steps here are also in #9024 |
||
|
|
||
| 1. Making the RC. From the ref you want to make release do: | ||
| 1. `git checkout -b release-vX.Y.Z` (create the branch this release is gonna be worked on) | ||
|
There was a problem hiding this comment. Look at the doc in rendered form. It isn't indented. I assume you need to add an extra space. |
||
| 1. Make changelogs if you havn't done so yet. | ||
| Changelogs are free flowing and can be done earlier on master if you want. | ||
| It is smart to add changelogs when you create a new big feature while or just after merging this feature instead of 2 weeks later when doing the release. | ||
| 1. Update the `version.go` file (must be it's own commit with nothing else). | ||
| 1. `git tag -s vX.Y.Z-rcAAA` create signed tags | ||
| 1. `git push origin vX.Y.Z-rcAAA` push the tag (never use `git push --tags`) | ||
| 1. Making the final release (/ an other RC) | ||
| 1. Doing Back-Ports. | ||
| - If you want to pull anything from `$(git merge-base release-vX.Y.Z $REF)..$REF` do a merge commit from `$REF` into `release-vX.Y.Z`. | ||
| It's important to use merge for the merge algorithm to not see this as conflicts later. | ||
| If you don't understand that sentence just skip this step and go to the next one. | ||
| - For other commits do `git cherry-pick -x $COMMIT`. | ||
| Using `-x` will add `(cherry picked from commit ...)`, this make the merge algorithm to not see this as conflicts later. | ||
| 1. Finalize changelogs. | ||
| 1. Update the `version.go` file (must be it's own commit with nothing else). | ||
| 1. Merge `release-vX.Y.Z` into `release` branch (USE A MERGE COMMIT). | ||
| 1. `git tag -s vX.Y.Z` create a signed tag on that merge commit | ||
| 1. On a new temporary branch update `version.go` for the next release `-dev`. | ||
| 1. Using a merge commit (to avoid conflicts one last time) merge back that temporary thing into `master`. | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
A few concerns about this:
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 stared at it for a bit and it made sense as I worked through it, seems okay as supplemental material.
Also agree re: diagram source. We need to maintain these over time, they should be easy to change/update. GitHub supports rendering Mermaid diagrams natively now, would be nice to use that for diagramming: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams . There's even git graph support https://mermaid-js.github.io/mermaid/#/gitgraph