Multi-Release Train

The Hook (The "Byte-Sized" Intro)

Your v2.0 is in beta. Your v1.9 is in production. A critical bug needs a v1.9.1 patch. Meanwhile, v2.1 features are being developed. Three versions, all active at once. A multi-release train manages this with parallel release branches — each version has its own branch, its own CI, and its own deployment pipeline.

📖 What is a Multi-Release Train?

A workflow where multiple versions of software are maintained simultaneously using dedicated release branches, each receiving targeted fixes and features.

Conceptual Clarity

Active branches:

Branch	Version	Status
`main`	Next version	Active development
`release/2.0`	v2.0.x	Beta/staging
`release/1.9`	v1.9.x	Production (LTS)
`release/1.8`	v1.8.x	Security fixes only

Fix flow direction (always forward):

Fix Applied To	Also Cherry-Pick To
`release/1.8`	`release/1.9` → `release/2.0` → `main`
`release/1.9`	`release/2.0` → `main`
`release/2.0`	`main`

Real-Life Analogy

A multi-release train is like a transit system with express and local trains running on parallel tracks. The express (main) gets new features. The local (release branches) get maintenance. If you fix a track issue on the local line, you also fix it on the express.

Visual Architecture

gitGraph commit id: "v1.8.0" branch release/1.9 commit id: "v1.9.0" branch release/2.0 commit id: "v2.0-beta" checkout main commit id: "v2.1-dev" checkout release/1.9 commit id: "v1.9.1 patch" checkout release/2.0 commit id: "cherry-pick patch" checkout main commit id: "cherry-pick patch 2"

Why It Matters

LTS support: Older versions can receive security patches.
Beta testing: New versions can be tested without affecting production.
Customer choice: Enterprise customers often stay on older versions.
Risk isolation: Work on v2.0 doesn't affect v1.9 production.

Code

bash

# ─── Create release branches ───
git checkout -b release/2.0 main
git push origin release/2.0

# ─── Hotfix on production version ───
git checkout release/1.9
git checkout -b hotfix/security-patch
# Fix, commit...
git checkout release/1.9 && git merge hotfix/security-patch
git tag v1.9.1

# ─── Cherry-pick fix forward ───
git checkout release/2.0
git cherry-pick <hotfix-sha>
git checkout main
git cherry-pick <hotfix-sha>

# ─── List all release branches ───
git branch --list 'release/*'

# ─── Compare versions ───
git log --oneline release/1.9..release/2.0  # What's new in 2.0

Key Takeaways

Use dedicated release branches for each supported version.
Fixes flow forward: oldest version → newest → main.
Cherry-pick fixes to newer branches; don't merge release branches into each other.
This pattern is common in enterprise and LTS products.

Interview Prep

Q: How do you manage multiple active versions of software? A: With parallel release branches (release/1.9, release/2.0, etc.). Each branch has its own CI/CD and receives targeted fixes. Bug fixes are cherry-picked forward from older to newer branches.
Q: Why do fixes flow forward, not backward? A: Newer branches have features that older branches don't. Merging backward would introduce unwanted changes. Cherry-picking forward ensures each fix is applied cleanly to all affected versions.
Q: When would you use a multi-release train? A: When you need to support multiple versions simultaneously — enterprise software with LTS releases, mobile apps with staggered rollouts, or products where customers choose which version to use.