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

[Andreas Schumacher]

Right now, release candidates are only planned for major releases.

For patch releases: In theory, you can not assume that there are no 
changes to the language and beam level in a patch release. In practice, 
you may want to assume it; AFAIK, there hasn't been such a change in a 
patch release.

Andreas

On 02/07/2014 01:10 PM, Andreas Schumacher wrote:
>
> -----Original Message-----
> From: Vlad Dumitrescu [mailto:vladdu55@REDACTED]
> Sent: den 7 februari 2014 12:59
> To: Andreas Schumacher
> Cc: erlang-questions
> Subject: Re: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released.
>
> Thank you very much for the versioning specification. It makes it all
> much clearer.
>
> Just a couple of details are still fuzzy for me:
>
> - release candidates will exist only for major relesess, right?
>
> - for patch releases, can we at least assume that there are no changes
> at the languageand beam level, that it that X.Y.Z.1.0.0.1 will be able
> to compile with the X.0 compiler and execute on a X.Y runtime (even if
> the results aren't the right ones in the latter case because of what
> was fixed in the patch)?
>
> best regards,
> Vlad
>
>
> On Fri, Feb 7, 2014 at 12:20 PM, Andreas Schumacher <andreas@REDACTED> 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 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
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions