Hotfix / Patch Release Strategy

Used when a shipped version needs a fix while develop has already moved on to the next minor, so the fix can't route through the normal develop → qa → main flow without dragging in unfinished work.

Example: main is on 1.1.0 (latest stable), develop is mid-work on 1.2.0, and a customer needs a 1.1.1 patch.

main is never touched by this flow — not even a fast-forward. It stays at 1.1.0 for as long as 1.1.x is the shipping line; release/1.1 and its tags are the actual record of what shipped as 1.1.1, 1.1.2, etc.

Steps

1. Cut release/1.1 from main's current tip (the 1.1.0 release) in every repo — including repos with no code change, since every service gets rebuilt and relabeled together for the patch.
2. Apply the actual fix only in the repo(s) where the bug lives; the rest just carry the version bump.
3. Run the standard version-bump script on release/1.1 in all repos, bumping version.txt to 1.1.1 everywhere.
4. Tag 1.1.1 directly on release/1.1 in every repo — main is not merged into, fast-forwarded, or touched in any way.
5. Build, tag, publish, and release manually per repo for now. Today's on.push.branches triggers (in every repo's build_push.yml, and in mcm-devops's setup-deploy routing) only recognize develop, qa, and main — a push to release/1.1 doesn't fire any of that automation. Until the CI trigger list is extended to recognize release/** (see Deployment Environments), this step means dispatching each affected repo's build manually (workflow_dispatch against the release/1.1 ref) rather than getting it for free from a push.
6. Ship the artifact bundle the same way any main release does. As covered on the previous page, main releases don't auto-deploy to any internal environment either — production is always "publish the artifact, customer/Ops installs it." A 1.1.1 hotfix follows the identical path: bundle mcm_artifacts_1.1.1.tar.gz, publish it, and have the customer (or Ops, on their behalf) run upgrade.sh.
7. Keep release/1.1 alive per repo instead of deleting it — it's the branch for 1.1.2, 1.1.3, and any later patch to the same line.
8. Manually port the fix into develop (and qa). There is no automated forward-merge, so link the release/1.1 fix commit in a tracked ticket/PR so it doesn't silently drop out of 1.2.0 when that ships.

Open item: CI trigger update

For step 5 to stop being a manual chore, two changes are needed (not yet made):

• Add release/** to the on.push.branches list in every repo's build_push.yml, its version-calculation branch (treat release/* like main — no version suffix, since this is a real release), the Create GitHub Release condition, and the trigger-devops condition.
• Add explicit routing for release/* in mcm-devops's setup-deploy job so it doesn't fall through to the shared Feature VM if an internal verification deploy is wanted before shipping the artifact.

These are CI/CD pipeline changes across ~18 repos — worth doing deliberately in a follow-up, not as a side effect of writing this doc.