[erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released.

[Andreas Schumacher]

We changed the version scheme for two reasons: For the first, we 
abandoned the R-version scheme, since it has a meaning inside Ericsson 
that differs from how we used it; that caused some confusion. Secondly, 
we adapted a version scheme that allows us to bookkeep fine-grained 
patches on arbitrary OTP versions to our customers with support agreements.

The new version scheme is *not* semantic versioning; although, it has 
been inspired by it. We do not want to use semantic versioning (as 
defined by http://semver.org/) out of the box since it does not fit our 
needs. Most importantly, we must be able branch out from any old version 
and also be able to do so multiple times. This is not possible when 
limited to only using MAJOR.MINOR.PATCH as version numbers. For example, 
if we have released 17.0, 17.0.1, and 17.0.2 we may have to release a 
patch based on 17.0.1. In this case it will be given the version 17.0.1.1.

A new MAJOR release is denoted with <X>.0, where <X> is incremented by 
one at the delivery of a new major release, which may contain potential 
incompatibilities.

A pre-release is denoted with <X>.0-rc<N>, where <N> starts with 1 at 
the delivery of the first pre-release, and is incremented by one for 
each subsequent pre-release. "-rc0" will be used during development up 
to the first release candidate. Pre-releases <X>-rc<N> sort before <X>. 
Apart from <X>-rc<N>, there are no plans for other special parts; 
although that might change if the need arises.

A MINOR and/or PATCH (bug-fix) release is denoted with <X>.<Y>.<Z>, where:
- <Y> is set to 0 when <X> is incremented and is incremented by one when 
new (minor)
   functionality is released. <Y> is used even when <Y> == 0.
- <Z> is set to 0 when <X> or <Y> is incremented, and incremented by one 
when only bug
   fixes are released. <Z> is not used when <Z> == 0, unless [support 
patches] patches are based on that version; see below.

Everything in a version V0 = <X>.<Y0>.<Z0> is included in a version V1 = 
<X>.<Y1>.<Z1> if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 
&& Z1 > Z0).

The OTP major release and the complete OTP version can be retrieved from 
erlang code using the following:

    1> erlang:system_info(otp_release).
    "17"
    2> erlang:system_info(otp_correction_package).
    "17.0-rc1"

NOTE: The name of the argument "otp_correction_package" will be changed 
to "otp_version." In addition, a corresponding flag "otp_version" will 
be added to the erl command, in order to allow the extraction of the 
complete version number from command line tools.

Version changes in applications imply a version change on OTP level, but 
they are not propagated one-to-one; especially, a change of the major 
version of an application does not necessarily imply a change of the 
major version at the OTP level. The mapping is a case-by-case decision 
that depends on the application, the type of functionality, impacts on 
backward compatibility, etc.

It is basically only the releases of the form <X>.<Y>.<Z> that are of 
interest for the Erlang open source community. However, from OTP 17.0 we 
will only deliver source code releases [even to our customers with 
support agreements]; and thus, even traces of support-patch 
release-versions on top of those regular releases are going to be 
visible in the public Erlang/OTP Git repository. The following is a 
brief description of the format of those patch releases:

When branching out, we add ".1" at the end of <X>.<Y>.<Z>, unless this 
version number has already been used. If it has already been used, we 
search for an unused version number by adding more and more ".0" between 
the version we are branching from, and the ".1" that we add at the end. 
For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and 17.0.1.0.0.0.1 are 
all versions of modifications based on version 17.0.1.

When basing a patch or a feature on an already branched version that do 
not require any new branching, we increase the last part of the version.

When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, 
you cannot
draw any conclusions about the specific modifications in the version, 
but you can see what the modifications are based on.

The Erlang/OTP Team at Ericsson