# What is Release Train?

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](/glossary/release-notes/)) plus a running [changelog](/glossary/changelog/) covering the trail of trains. Patch trains get their own (smaller) release notes entries between major trains.

## Related terms

- [Canary Release](/glossary/canary-release/)
- [Breaking Change](/glossary/breaking-change/)
- [Deprecation Policy](/glossary/deprecation-policy/)
- [Changelog](/glossary/changelog/)



Category: Release Engineering
Last reviewed: 2026-05-28