[erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released.
Fri Feb 7 13:24:23 CET 2014
The change of version scheme does not (necessarily) imply a change of
the release cycle. The current plan is to release 17.0 in March and up
to three additional OTP 17-based minor releases this year. When OTP 18.0
will be released has not been decided, yet.
Indded, one of the (long-term) ambitions with moving to source code
releases and an improved patch handling is to allow for a faster release
> -----Original Message-----
> From: Loïc Hoguin [mailto:]
> Sent: den 7 februari 2014 12:56
> To: Andreas Schumacher;
> Subject: Re: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released.
> Sounds good.
> One question though. Does that mean the current cycle of having a major
> release every year will be changed, or should we still more or less
> expect a new major at the beginning of the year and three or four minor
> releases after that?
> I hope that having source code only and a proper PATCH number will allow
> much faster release of fixes when a release is significantly broken
> (like for example the R16B03's syntax_tools application issue --
> R16B03-1 took a long time to get released).
> On 02/07/2014 12:20 PM, Andreas Schumacher wrote:
>> 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 220.127.116.11.
>> 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
>> 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).
>> 2> erlang:system_info(otp_correction_package).
>> 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, 18.104.22.168, 22.214.171.124.1, 126.96.36.199.0.1, and 188.8.131.52.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
>> erlang-questions mailing list
More information about the erlang-questions