What is Release Train?
Last reviewed May 28, 2026
A release train is a fixed-cadence release model where new versions of a product ship on a predictable schedule — every six weeks, every quarter, twice a year — regardless of which features happen to be ready. Features that miss the cutoff for one train wait for the next; the train itself doesn't slip. The model is most common in browser engines (Chromium), operating systems (iOS, Android), and platform releases (Kubernetes) where downstream consumers value predictability over flexibility.
Example
Chromium ships a new stable release every four weeks; whatever isn't merged by the branch-cut date waits for the next train. iOS ships a major version every year in September; whatever Apple hasn't finished by WWDC waits a full year. Kubernetes ships a minor release every four months. In all three cases the release date is announced years ahead, and the team commits to the date, not to the scope.
Why it matters
Release trains trade flexibility for predictability. For ecosystems where many downstream consumers schedule their own work around your release dates (browser-extension authors, mobile app developers, platform users), predictability is the higher-value property — they can plan their own roadmaps against yours. The cost is real: features that miss a train slip by the full cadence, which can be frustrating for the team that built them. Not every product is right for the release train model; most SaaS shipping continuously isn't.
More context
The release-train discipline rests on three operational habits:
A published cadence, far enough out that consumers can plan against it. Chromium publishes the next 12 months of release dates on a public calendar. iOS announces the major version date at WWDC every June. The cadence doesn't have to be short — yearly is fine — but it has to be public and committed.
A hard branch-cut date for each train. Features merged before the date go on the train. Features merged after the date go on the next train. There's no exception process; the train doesn't wait for "almost done." The discipline is brutal at first and becomes culture over time.
Patch trains for fixes that can't wait. A release-train model doesn't mean every bug fix waits for the next major. Most products that run trains also run patch trains — smaller, more frequent releases (Chromium does weekly stable updates between major-version trains) that ship critical fixes without breaking the main cadence.
For SaaS products shipping continuously to a hosted environment, release trains are usually overkill — there's no installation step for users to coordinate around, so the predictability value is lower. The model fits when your release dates are also your users' release dates: when shipping is an event they have to act on, the train model gives them the runway to do that.
In changelog terms, release trains map naturally to a per-train release notes entry (release notes) plus a running changelog covering the trail of trains. Patch trains get their own (smaller) release notes entries between major trains.