Release Policy and Versioning
As of Unblu 5, Unblu versions comply with the “Semantic Versioning” specification . Versions use a sequence of three digits (
<major>.<minor>.<patch>(.<qualifier>)) to describe the impact of an update of the software. The definition of impact in this scheme is usually measured in terms of public API, can also be described with the term “breaking changes”. In this scheme the version numbers and the way they change convey meaning about the underlying code - and what has been modified from one version to the next.
In summary the semantic meaning of the
<major>.<minor>.<patch> version scheme is defined as follows:
<major>digit increment is used when incompatible API changes are introduced,
<minor>digit increment is used when functionality is added in a backwards-compatible manner
<patch>digit increment is used when backwards-compatible bug fixes are being made.
Therefore Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
Release versions are sparse (e.g after
5.1.6 the next public version might be
When the version is updated with an increment of the
<minor> digit (this is called "new minor version"), then there will be no patch update anymore for the previous versions (e.g when
5.2.0 is released, if the previous version was
5.1.5 there is no
In addition to the public release, internal release exist to
Pre feature freeze versions: preview version, released in the early development phase.
Stabilization versions: after feature freeze, released before the first public version of a stream.
Alpha and beta versions only for major releases, there is no