Conversation
|
Need to add a step for managing the changelog that includes higher-level info, API change/deprecation, new feature, etc. |
|
Add a step to remove short-lived release branch (if rc or patch release). |
23dfd44 to
2494a06
Compare
docs/dev/RELEASE.md
Outdated
There was a problem hiding this comment.
I believe we need a release branch for minor releases so we can a) backport bug fixes b) push PRs for release-specific changes, e.g. quickstart guide.
docs/dev/RELEASE.md
Outdated
There was a problem hiding this comment.
if 4. is not needed, the release branch language will need to be rm'd
also helpful to share an example here #481
There was a problem hiding this comment.
See #325 (comment). Added an example with an xref to #481.
docs/dev/RELEASE.md
Outdated
There was a problem hiding this comment.
can this be combined with the above section with a note for line 4, saying if Release candidate add the rc.X suffix to the tag ?
There was a problem hiding this comment.
I did have both workflows initially combined, but I thought it started to get a bit convoluted as the steps began to deviate so I decided to create separate sections.
docs/dev/RELEASE.md
Outdated
There was a problem hiding this comment.
I don't think it should have the .0. Once a n x.y.z comes out, any necessary patch releases to it will be x.y.(z+1), so they'd still be in the same x.y release train. And it'd be misleading for z≠0 patch releases to be on a release/vX.Y.0 branch.
There was a problem hiding this comment.
@LukeShu this process is for a minor release. I would expect a patch release to be a separate documented process where we cherry-pick bug fixes to the release branch, tag the release branch with a new patch version and push the new tag to trigger the CI release process. Thoughts?
There was a problem hiding this comment.
I agree with what you're saying @danehans, but in that case, I think it makes sense to name the release branches release/vx.y rather than release/vx.y.0, since vx.y.0 and any other vx.y.z versions will be tags inside the relese/vx.y branch.
Signed-off-by: danehans <daneyonhansen@gmail.com>
Signed-off-by: danehans <daneyonhansen@gmail.com>
Codecov Report
@@ Coverage Diff @@
## main #325 +/- ##
==========================================
+ Coverage 60.22% 60.87% +0.65%
==========================================
Files 45 46 +1
Lines 5564 5570 +6
==========================================
+ Hits 3351 3391 +40
+ Misses 2006 1971 -35
- Partials 207 208 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Signed-off-by: danehans <daneyonhansen@gmail.com>
youngnick
left a comment
There was a problem hiding this comment.
Aside from the small change about not including the patch version in the release branch name, this LGTM.
docs/dev/RELEASE.md
Outdated
There was a problem hiding this comment.
I agree with what you're saying @danehans, but in that case, I think it makes sense to name the release branches release/vx.y rather than release/vx.y.0, since vx.y.0 and any other vx.y.z versions will be tags inside the relese/vx.y branch.
|
@youngnick thanks for the review. I'm going to merge this PR and resolve #325 (comment) shortly in a follow-up PR. |
Adds a doc to guide a release manager through the process of cutting a release.
Requires: #546
Fixes #15
Signed-off-by: danehans daneyonhansen@gmail.com