Software Release Modes: Project Release, Release Train, and Intercity Express

Nowadays, IT media hype DevOps, but let’s study the fundamentals because they fundamentally affect how you work.

Today we discuss software version release models.

When choosing a version release strategy, there are three adjustable dimensions: time, feature set, and quality.

Based on these three adjustment items, we can summarize three release modes:

Project Release Mode (项目制发布模式)

Traditional Release Train Mode (版本火车模式)

Intercity Express Mode (城际快线模式)

Project Release Mode means that for a given version plan, the set of features to be included is defined in advance; the version is released only after all those features are fully developed and meet the required quality standards. The interval between releases is not fixed but is determined by the time needed to complete the feature set and achieve release quality.

The obvious benefit is that each version’s functionality is clearly known, which supports commercial licensing models (selling version copies and maintenance fees, then charging for upgrades when new-feature versions are released). It also aligns with safety‑first practices by preventing unfinished features from being shipped.

The drawback is that the overall delivery cycle can be long and involves many participants. If requirements change during the cycle, the delivery schedule must be re‑evaluated, delaying all features that wait for the next joint release.

Traditional Release Train Mode is common in large suite‑type software. Enterprises with multiple product lines coordinate releases by planning a fixed schedule for each line, treating each version like a train that departs at a predetermined time. To keep the schedule, all teams must align their development phases, because a change in one line can affect others and shared integration environments. Typically the train runs on a quarterly window, rarely exceeding ten months.

When the train schedule is published, the release management team coordinates with all product teams months in advance and publishes the timetable (e.g., LibreOffice’s version‑train schedule).

Planning the train months ahead gives business and technical groups enough time for impact analysis and dependency planning, ensuring that time, quality, and feature dimensions meet expectations.

The advantages are that users can see which features will appear in which versions, experience new features early, and decide whether to adopt them after they mature.

The disadvantages are the need for lengthy upfront planning, a formalized process, and structured data (release identifiers, names, deployment dates, risk levels, type, lifecycle milestones, activities, quality requirements, and responsible owners).

Intercity Express Mode fixes two dimensions—time and quality—while keeping the time window short (often a week or even a day). Features that have reached the required quality are released at the scheduled point.

Its differences from the traditional train are: (1) much shorter release intervals, usually within two weeks; (2) feature teams can choose which express train to board without long‑term commitment.

This mode is common in internet‑service or SaaS companies. It reduces coordination costs because everyone knows the exact release times, and work can be aligned accordingly. Even if a feature misses the current release, the team knows when the next opportunity will be.

For example, Facebook’s main web site releases twice daily on workdays.

Advantages of the Intercity Express Mode include: (1) everyone knows the exact release times; (2) clear visibility of feature progress; (3) faster delivery speed; (4) stronger focus on production quality.

Its drawbacks are: (1) unfinished code may be released together with finished features; (2) constant pressure on the team; (3) if the release frequency slows, more planning time is required.

Choosing an appropriate release interval depends on the organization’s context, but a practical guideline is to shorten the cycle as much as possible without harming user experience, increasing cost, or violating compliance—e.g., moving from a monthly release to a bi‑weekly target.

When the release cycle is equal to or shorter than two weeks, teams are encouraged to adopt a trunk‑based development model, as branch‑merge overhead becomes a barrier.

In summary, Project Release Mode will continue to exist for initial MVP phases, especially in traditional IT enterprises, while the Intercity Express Mode is gaining popularity and is often blended into longer‑cycle projects as a fixed‑time iteration that delivers a potentially shippable product at each end.

Many internet companies have adopted the Intercity Express Mode; for instance, Facebook’s main site used it before 2010 and reached twice‑daily releases by 2012, while Google Chrome’s beta releases weekly and stable releases monthly follow a similar pattern.

Although Project Release will not disappear soon, the Intercity Express Mode serves as an indicator of a software delivery team’s capability.

How to build an Intercity Express Mode and improve continuous delivery capability? Join my public course “Continuous Delivery and DevOps Essentials” in Shanghai this August.