From ffe0848d09a83cd879a019835198c192d01f14bf Mon Sep 17 00:00:00 2001 From: Likhith Thammegowda Date: Tue, 4 Aug 2026 19:10:26 +0530 Subject: [PATCH] docs: cut release branch and tag from master, not the feature branch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The runbook contradicted itself: one line said to cut release artifacts from the merged trunk commit, another said a release run could create the branch and tag before the master merge. Following the second produced 4.2.9 and 4.2.11 as release branches pointing at fix-branch commits, so the deployed artifact was not reachable from master. State the rule once, with the commands, and record that master needs two approving reviews and cannot be merged programmatically — so the flow stops at the PR and the branch/tag come afterwards, from master. Also adds the --title "Release-X.Y.Z" flag that the documented gh command was missing; without it the release title defaults to the tag name. --- CLAUDE.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index 8ae02b3fe..cfbb3208a 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -206,7 +206,15 @@ Runtime config is fetched from `/apis/...` on app init. Access via `Configuratio ## Release Process - **Release notes** live in `RELEASE_NOTES/`; start from `RELEASE_NOTES/TEMPLATE.md`. File name: `RELEASE_NOTES/release-X.Y.Z.md`. - **Tag**: `vX.Y.Z` (immutable marker + GitHub Release). **Build/deploy branch**: `release-X.Y.Z` (Jenkins deploy source). Branch and tag names always differ. -- Flow: verify green (`nvs use 20` → lint + `yarn test` + `yarn run build`) → write release notes + version on a branch → PR into the trunk → cut `release-X.Y.Z` + tag `vX.Y.Z` → publish the GitHub Release from the tag (`gh release create vX.Y.Z --notes-file RELEASE_NOTES/release-X.Y.Z.md`) → manual Jenkins deploy from the **branch**. +- Flow: verify green (`nvs use 20` → lint + `yarn test` + `yarn run build`) → write release notes + version on a branch → PR into `master` → **wait for the merge** → cut `release-X.Y.Z` + tag `vX.Y.Z` **from `master`** → publish the GitHub Release from the tag (`gh release create vX.Y.Z --notes-file RELEASE_NOTES/release-X.Y.Z.md --title "Release-X.Y.Z"`) → manual Jenkins deploy from the **branch**. +- **`release-X.Y.Z` and `vX.Y.Z` are always cut from `master`, never from the feature/fix branch.** The release branch must point at the merged trunk commit, so what deploys is what `master` contains and what reviewers approved. Cutting from the fix branch produces a release that isn't reachable from `master` and silently diverges the deployed artifact from the trunk: + + ```bash + git fetch origin + git branch release-X.Y.Z origin/master + git tag vX.Y.Z origin/master + ``` +- **`master` requires 2 approving reviews and cannot be merged programmatically** (the API returns `405`). Automate up to opening the PR, then stop and wait for the approvals. Do not create the branch/tag/Release early to unblock a deploy — that is what produces off-trunk releases. - Each release gets its own new `release-X.Y.Z`; never advance a previous/frozen release branch. Rollback = redeploy the previous release branch. - Release notes structure: header table, plain-language Summary, ✨ Features, 🐛 Fixes, 🏗️ Build/CI, 📚 Docs/Chore, ⚠️ Deploy notes & risk, ✅ Pre-deploy checklist, Release & rollback. Each bullet ends with its short commit SHA.