infra: reorganize the RELEASE_CHECKLIST to group version change steps#1605
infra: reorganize the RELEASE_CHECKLIST to group version change steps#1605
RELEASE_CHECKLIST to group version change steps#1605Conversation
…ther. We previously created a pattern where some of the manual version changes that needed to be made were appearing in the "Prepare a Changelog (Full release only)" section and some were in the "Start a release PR" section. This wasn't the right organization and I found this to be counterintuiative since many of the version bumps were actually important to make even for non-full-releases and further challenging because they weren't about the changelog but rather version bumps which were also happening in the other section. This puts all the (too many) steps in one ordered list.
This comment has been minimized.
This comment has been minimized.
garypen
left a comment
garypen
left a comment
There was a problem hiding this comment.
I feel like having all the software you need in step 1 (or step 0) would be an improvement.
| 5. Update `helm/chart/router/Chart.yaml` and in `helm/chart/router/README.md` as follows: | ||
| - increment the version. e.g. `version: 0.1.2` becomes `version: 0.1.3` | ||
| - update the appVersion to the release version. e.g.: `appVersion: "v0.9.0"` | ||
| 6. cd helm/chart && helm-docs router; cd - (if required, install [helm-docs](https://github.com/norwoodj/helm-docs)) |
There was a problem hiding this comment.
Maybe we should expand step 1 with all the things you need to have installed?
I think the list is:
- cargo
- cargo-about (plugin)
- helm-docs
- rustc (via rustup or whatever)
- ...
We don't mention that you need rust right now, but you won't be able to run xtask without it...
There was a problem hiding this comment.
I like the suggestion, but wouldn't that be a DEVELOPMENT.md concern? Those seem like commands you need to
do development not just releasing (and I would expect development should be a requirement/precursor to releasing)
I could imagine the first step be a bullet-point that points to that description in DEVELOPMENT.md.
There was a problem hiding this comment.
Also, I now realize you're talking about an actual step 0, not using 0. to get around explicit numbering. (For context: We discussed this on an audio call.)
Agree (see comment above). But adding more steps to this list is not what this PR aims to do (see title). 😉 Put another way, can we approve this and follow-up? |
|
Thanks! We have #155 — so i'll add the software requirements to that. |
2 participants
We previously created a pattern where some of the manual version changes
that needed to be made were appearing in the "Prepare a Changelog (Full
release only)" section and some were in the "Start a release PR" section.
This wasn't the right organization and I found this to be counterintuiative
since many of the version bumps were actually important to make even for
non-full-releases and further challenging because they weren't about the
changelog but rather version bumps which were also happening in the other
section.
This puts all the (too many) steps in one ordered list.