Release models

As Semantic Versions describe three types of changes (bug-fix patches, backward compatible feature additions, and incompatible interface changes), we can describe three primary release models. Each of those models provides release streams that are limited to a type of change described by SemVer.

A minor-version stable release model provides release streams that provide only bug fixes. A major-version stable release model provides release streams that include both bug fixes and backward compatible feature additions. A rolling release model provides release streams (or, more typically one continuous release stream) that includes bug fixes, backward compatible features, and incompatible interface changes.

Critically, release streams are only meaningfully separate if they overlap. There is no functional difference between a rolling release and a “stable” release with a purely linear release sequence. Both of those models support the same workflows and provide users with the same options.

For example, a vendor might publish version 1.5.8, followed by 1.6.0, and no further releases of the 1.5 series. They might later publish version 2.0.0, and no further releases of the v1 series. This model looks vaguely like a stable release, but this system’s users get bug fixes, new features, and incompatible changes as they update, and they have no option to get bug fixes without new features or changes that aren’t backward-compatible.

Efficiency

So, why would a vendor publish version 1.5.9 after releasing 1.6.0? Why would they publish version 1.8.0 after releasing 2.0.0?

Continued maintenance of an existing release stream after a new one begins isn’t very efficient. As a vendor makes the maintenance window for a release stream longer, or as new release streams become more frequent, the number of release streams being maintained increases, and the engineering effort required to maintain them increases as well.

There is a benefit, though, because continued maintenance of existing release streams allows different developer groups to work on asynchronous schedules. It decouples teams from each other, so that each group of developers does not need to coordinate changes landing at the same time.

Inefficiency increases development velocity, because it provides the structure required to support groups developing at their own pace.

Why do we need distributions?

The strength of the stable release model is also its weakness. Free Software platforms are composed of thousands of components releasing on asynchronous, independent schedules, enabled by stable release model.

But that freedom and diversity becomes complexity very quickly. The stable release model allows an application developer to migrate from one release stream of a dependency to another on their own schedule, but if an application has many dependencies and if they don’t have similar schedules, developers may spend a lot of time porting from release to release, of component after component.

[ Place an illustration here, which depicts the release cycles of a number of core system components. ]

Distributions can help tame that complexity by creating something that looks like a single coherent platform, with one release cadence and maintenance window for many of the shared components that application developers rely on.

[ Place an illustration here which depicts the release cycle of a distribution. ]