From dd44bba6b65a4d5776c2799387e96f72197c77ba Mon Sep 17 00:00:00 2001 From: latin-panda <66472237+latin-panda@users.noreply.github.com> Date: Tue, 11 Aug 2026 13:11:05 +0700 Subject: [PATCH 1/3] update release templates --- .github/ISSUE_TEMPLATE/patch_release.md | 11 +++++++---- .github/ISSUE_TEMPLATE/release.md | 4 ++-- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/patch_release.md b/.github/ISSUE_TEMPLATE/patch_release.md index b102f34b3..786a83a23 100644 --- a/.github/ISSUE_TEMPLATE/patch_release.md +++ b/.github/ISSUE_TEMPLATE/patch_release.md @@ -32,10 +32,11 @@ Releasing requires two people: one person to push PRs and complete other tasks a > Optional section: skip it if no `central-frontend` changes are included in the patch. -- [ ] Run `npm run version` in `central-frontend`. This consumes the `.changeset/` files, bumps package versions, and updates each `CHANGELOG.md`. -- [ ] Commit the changes on a new branch (e.g., `release-version-bumps`) and open a PR targeting `master`. -- [ ] 🔎 Review the PR. Verify the version bumps and `CHANGELOG.md` entries match what's expected from the `.changeset/` files. -- [ ] Merge the PR. +- [ ] Check out the `central-frontend` hotfix branch for the patch, and cherry-pick the commits for the patch from `master` onto it. +- [ ] Run `npm run version` in `central-frontend`, then `npm install`. This consumes the `.changeset/` files, bumps package versions, updates each `CHANGELOG.md`, and updates `package-lock.json`. +- [ ] Commit the changes on a new branch and open a PR targeting the hotfix branch. +- [ ] 🔎 Review the PR. Verify the cherry-picked commits, the version bumps and `CHANGELOG.md` entries match what's expected from the `.changeset/` files, and that `package-lock.json` was updated. +- [ ] Merge the PR into the hotfix branch. - [ ] In `central-frontend`, create a minimal GitHub release on the merged commit. The tag push is what triggers `.github/workflows/wf-publish.yml` to publish packages to npm — full release notes live only in the `central` release. - Tag: `v*.*.*` (no pre-release suffix). - Set as the **latest release**. Don't set as a pre-release. @@ -45,6 +46,8 @@ Releasing requires two people: one person to push PRs and complete other tasks a - 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`. +- [ ] 🔎 Review the PR. Verify the `CHANGELOG.md` entries match the hotfix branch and that only the changesets included in the patch were deleted. Merge it. ### Release `central-backend` diff --git a/.github/ISSUE_TEMPLATE/release.md b/.github/ISSUE_TEMPLATE/release.md index 39d4be8a9..a5ebce004 100644 --- a/.github/ISSUE_TEMPLATE/release.md +++ b/.github/ISSUE_TEMPLATE/release.md @@ -33,9 +33,9 @@ Releasing requires two people: one person to push PRs and complete other tasks a > Releases always include `central-frontend`. -- [ ] Run `npm run version` in `central-frontend`. This consumes the `.changeset/` files, bumps package versions, and updates each `CHANGELOG.md`. +- [ ] Run `npm run version` in `central-frontend`, then `npm install`. This consumes the `.changeset/` files, bumps package versions, updates each `CHANGELOG.md`, and updates `package-lock.json`. - [ ] Commit the changes on a new branch (e.g., `release-version-bumps`) and open a PR targeting `master`. -- [ ] 🔎 Review the PR. Verify the version bumps and `CHANGELOG.md` entries match what's expected from the `.changeset/` files. +- [ ] 🔎 Review the PR. Verify the version bumps and `CHANGELOG.md` entries match what's expected from the `.changeset/` files, and that `package-lock.json` was updated. - [ ] Merge the PR. - [ ] In `central-frontend`, create a minimal GitHub release on the merged commit. The tag push is what triggers `.github/workflows/wf-publish.yml` to publish packages to npm — full release notes live only in the `central` release. - Tag: `v*.*.*` (no pre-release suffix). From b0c0c8c08b2c50128723911052715810d3e21776 Mon Sep 17 00:00:00 2001 From: latin-panda <66472237+latin-panda@users.noreply.github.com> Date: Fri, 14 Aug 2026 00:39:13 +0700 Subject: [PATCH 2/3] feedback --- .github/ISSUE_TEMPLATE/patch_release.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/patch_release.md b/.github/ISSUE_TEMPLATE/patch_release.md index 786a83a23..a7e51b931 100644 --- a/.github/ISSUE_TEMPLATE/patch_release.md +++ b/.github/ISSUE_TEMPLATE/patch_release.md @@ -26,7 +26,7 @@ Releasing requires two people: one person to push PRs and complete other tasks a - [ ] Get the latest version of the `central` repository locally. - If you have **not** cloned the repository: clone it. - If you had **already** cloned the repository: `git pull` -- [ ] Check out the correct branch. If the patch involves a single change/PR to the `central` repository, check out the `master` branch. Otherwise, a different branch will be used for the patch (possibly `next`); check out that branch. +- [ ] Check out the correct branch. If the patch involves a single change/PR to the `central` repository, check out the `master` branch. Otherwise, use a patch branch off `master` (never `next`, which may contain changes not intended for the patch); check out that branch. ### Release `central-frontend` @@ -46,14 +46,16 @@ Releasing requires two people: one person to push PRs and complete other tasks a - 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`. -- [ ] 🔎 Review the PR. Verify the `CHANGELOG.md` entries match the hotfix branch and that only the changesets included in the patch were deleted. Merge it. +- [ ] On a new branch off `central-frontend`'s `master`, cherry-pick the version commit from the hotfix branch. Open a PR targeting `master`. +- [ ] 🔎 Review the PR. Verify it matches the version commit on the hotfix branch. Merge it to `master`. ### Release `central-backend` > 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`. +- [ ] Check out the `central-backend`'s hotfix branch, cherry-pick the commits for the patch from `master` onto it, and push the branch. +- [ ] 🔎 Verify the cherry-picked commits on the hotfix branch match what's expected for the patch. +- [ ] Create a GitHub release on the tip of the hotfix branch. - Tag: `v*.*.*` (no pre-release suffix). - Set as the **latest release**. Don't set as a pre-release. - Body: a single line pointing to the upcoming `central` release, e.g., `See release notes at https://github.com/getodk/central/releases/tag/vX.Y.Z`. @@ -62,17 +64,16 @@ Releasing requires two people: one person to push PRs and complete other tasks a - [ ] If the patch includes `central-backend` changes, `cd server` and run: - `git fetch` - - `git switch -d origin/master` or `git checkout origin/master` + - `git switch -d vXXXX.X.Y` (the `central-backend` release tag created above) - [ ] 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. + - If the only change/PR to the `central` repository is these updates, target the `master` branch. Otherwise, target the patch branch. - [ ] 🔎 Review the PR. Verify that the `server` diff links to the expected commit hashes and that `FRONTEND_VERSION` matches the `central-frontend` release tag. ### 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. +- [ ] 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, targeting `master`. Merge it to `master`. - Select **"Create a merge commit"** when you merge. - - If the PR used the `next` branch, don't delete the `next` branch after merging. ### Release `central` @@ -122,4 +123,4 @@ Releasing requires two people: one person to push PRs and complete other tasks a > Do this once the news PR has been merged. -- [ ] If there has been a commit to the `next` branch that isn't on the `master` branch, then merge the `master` branch into the `next` branch. If there has not been a commit, then reset the `next` branch to the tip of the `master` branch. \ No newline at end of file +- [ ] If there has been a commit to the `next` branch that isn't on the `master` branch, then merge the `master` branch into the `next` branch. If there has not been a commit, then reset the `next` branch to the tip of the `master` branch. From c3bc4c34c682a3a0782bd493a28f2e75dd74d10e Mon Sep 17 00:00:00 2001 From: latin-panda <66472237+latin-panda@users.noreply.github.com> Date: Fri, 14 Aug 2026 00:52:13 +0700 Subject: [PATCH 3/3] fixes wording --- .github/ISSUE_TEMPLATE/patch_release.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/patch_release.md b/.github/ISSUE_TEMPLATE/patch_release.md index a7e51b931..09bfd00c9 100644 --- a/.github/ISSUE_TEMPLATE/patch_release.md +++ b/.github/ISSUE_TEMPLATE/patch_release.md @@ -26,13 +26,13 @@ Releasing requires two people: one person to push PRs and complete other tasks a - [ ] Get the latest version of the `central` repository locally. - If you have **not** cloned the repository: clone it. - If you had **already** cloned the repository: `git pull` -- [ ] Check out the correct branch. If the patch involves a single change/PR to the `central` repository, check out the `master` branch. Otherwise, use a patch branch off `master` (never `next`, which may contain changes not intended for the patch); check out that branch. +- [ ] Check out the correct branch. If the patch involves a single change/PR to the `central` repository, check out the `master` branch. Otherwise, use a hotfix branch off `master` (never `next`, which may contain changes not intended for the patch); check out that branch. ### Release `central-frontend` > Optional section: skip it if no `central-frontend` changes are included in the patch. -- [ ] Check out the `central-frontend` hotfix branch for the patch, and cherry-pick the commits for the patch from `master` onto it. +- [ ] Check out the `central-frontend` hotfix branch for the patch (create it from the previous release tag if it doesn't exist), and cherry-pick the commits for the patch from `master` onto it. - [ ] Run `npm run version` in `central-frontend`, then `npm install`. This consumes the `.changeset/` files, bumps package versions, updates each `CHANGELOG.md`, and updates `package-lock.json`. - [ ] Commit the changes on a new branch and open a PR targeting the hotfix branch. - [ ] 🔎 Review the PR. Verify the cherry-picked commits, the version bumps and `CHANGELOG.md` entries match what's expected from the `.changeset/` files, and that `package-lock.json` was updated. @@ -53,7 +53,7 @@ Releasing requires two people: one person to push PRs and complete other tasks a > Optional section: skip it if no `central-backend` changes are included in the patch. -- [ ] Check out the `central-backend`'s hotfix branch, cherry-pick the commits for the patch from `master` onto it, and push the branch. +- [ ] Check out the `central-backend` hotfix branch for the patch (create it from the previous release tag if it doesn't exist), cherry-pick the commits for the patch from `master` onto it, and push the branch. - [ ] 🔎 Verify the cherry-picked commits on the hotfix branch match what's expected for the patch. - [ ] Create a GitHub release on the tip of the hotfix branch. - Tag: `v*.*.*` (no pre-release suffix). @@ -67,7 +67,7 @@ Releasing requires two people: one person to push PRs and complete other tasks a - `git switch -d vXXXX.X.Y` (the `central-backend` release tag created above) - [ ] 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, target the patch branch. + - If the only change/PR to the `central` repository is these updates, target the `master` branch. Otherwise, target the hotfix branch. - [ ] 🔎 Review the PR. Verify that the `server` diff links to the expected commit hashes and that `FRONTEND_VERSION` matches the `central-frontend` release tag. ### Merge