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

[Thomas Lindgren]

"    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.""


Any possibility of changing the naming conventions to something more easily memorized?  For example, otp_major_release ("17") vs otp_release ("17.0-rc1"). (Presumably, the second one is the one people will usually want to know?) 

Not to say I'm committed to what I just proposed, but I just know I shall evermore have to consult the manual to get otp_release and otp_version straight.

(Also, consider if there ever were to be a second supplier of erlang. Wouldn't it be better to use option names that do not include "otp" to get this information?)

Best,
Thomas




On Friday, February 7, 2014 12:36 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140207/02c19f36/attachment.htm>