chore: add missing steps to release templates - #2116
Conversation
|
@garethbowen I'm leaving this PR open in case there are more things to fix or add. Feel free to contribute or comment on anything you'd like to fix or add. |
|
There definitely are... I'll update once I get the release out. |
| - The expected packages were published to npm. | ||
| - Per-package tags were pushed to the repository. | ||
| - If the workflow fails, do not proceed with the rest of the release — investigate and resolve before creating the `central` release. | ||
| - [ ] Bring the release notes back to `master`: on a new branch off `central-frontend`'s `master`, copy the new `CHANGELOG.md` entries from the hotfix branch and delete the `.changeset/` files that the patch consumed (leave changesets for changes that weren't part of the patch). Open a PR targeting `master`. |
There was a problem hiding this comment.
It might be better to cherry-pick the commit from the hotfix branch?
There was a problem hiding this comment.
It might not be tested by QA unless we request to deploy the hotfix branch to a server 🤔 Otherwise, I'd cherry-pick from the hotfix branch.
There was a problem hiding this comment.
I'm just talking about the commit with the versions, changelog, and changeset deletions. If that is done as a single commit then you can cherry-pick it into master and you don't risk making typos or deleting the wrong changeset.
|
|
||
| > Optional section: skip it if no `central-backend` changes are included in the patch. | ||
|
|
||
| - [ ] Create a GitHub release on the latest `master` commit of `central-backend`. |
There was a problem hiding this comment.
I think backend should follow the same process as frontend, ie: hotfix branch, cherry-pick, and then release from that.
| - `git switch -d origin/master` or `git checkout origin/master` | ||
| - [ ] If the patch includes `central-frontend` changes, update `FRONTEND_VERSION` in `docker-compose.yml` to the tag of the `central-frontend` release created above. | ||
| - [ ] Commit the updates using a new branch (e.g., `update-versions`). Create a new PR for the branch. | ||
| - If the only change/PR to the `central` repository is these updates, target the `master` branch. Otherwise, a different branch will be used for the patch (possibly `next`); target that branch. |
There was a problem hiding this comment.
I think this is where I went wrong... I don't think a patch should target next because it'll pick up changes that aren't intended for this patch.
There was a problem hiding this comment.
Sounds right, I'll update this
|
|
||
| ### Merge | ||
|
|
||
| - [ ] If the patch involves more than a single change/PR to the `central` repository, then there should be a PR for the patch as a whole. Merge it. |
There was a problem hiding this comment.
It'd be helpful to say "Merge it to master"
2 participants
Warning
Branch off and target
next, notmaster. Themasteris stable and used in production (exception: documentation/infrastructure-only changes).What has been done to verify that this works as intended?
Steps taken in patch release 2026.2.2
Why is this the best possible solution? Were any other approaches considered?
Tracks missing steps
How does this change impact users? Describe intentional behavior changes from code updates. What are the regression risks?
no
Does this change require updates to documentation? If so, please file an issue here and include the link below.
no