Release train
A release that leaves on a fixed recurring schedule; ready features ship, and anything unfinished waits for the next one.
What it is
A release train ships on a fixed recurring schedule, with whatever qualified work is ready when the cutoff arrives. The date does not slide to wait for one feature; unfinished work misses this train and catches the next one. The railway metaphor is the operating rule, not just a project name.
Reach for it when many teams contribute to one product and ad hoc launches create coordination churn. A weekly or fortnightly cadence gives QA, support, marketing, and operations predictable cutoffs while making the cost of missing one release small. Chrome runs the largest public version of this: a new stable release every four weeks, and a feature that misses the branch point waits for the next one.
Gotcha: a fixed date becomes a deadline panic if partially finished work must ship. Keep changes small, hide incomplete paths behind feature flags, and define objective boarding checks. The train leaves on time because scope moves, not because quality checks disappear.
Ask AI for it
Create a weekly release train with GitHub Actions. Schedule preparation for Monday at 15:00 UTC with `0 15 * * 1`: collect merged pull requests carrying the train-ready label, generate a SemVer release candidate and GitHub Release notes, and run integration, migration, and smoke tests against that exact artifact. Schedule departure for Tuesday at 15:00 UTC with `0 15 * * 2`, promoting the same digest only if every check passes. Add workflow_dispatch fallbacks because scheduled runs can be delayed. Leave unready work behind a feature flag or move it to the next GitHub Milestone; never move the departure time. Document the hotfix exception and release owner rotation.