<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10pt"><div><span><br></span></div><span style="font-family: monospace;">"    1> erlang:system_info(otp_release).</span><br style="font-family: monospace;"><span style="font-family: monospace;">    "17"</span><br style="font-family: monospace;"><span style="font-family: monospace;">    2> erlang:system_info(otp_correction_package).</span><br style="font-family: monospace;"><span style="font-family: monospace;">    "17.0-rc1"</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">NOTE: The name of the argument "otp_correction_package" will be changed </span><br style="font-family: monospace;"><span style="font-family: monospace;">to "otp_version.""</span><br style="font-family:
 monospace;"><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span>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?) </span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
 HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span>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.</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">(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?)</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica
 Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span>Best,</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span>Thomas</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div class="yahoo_quoted" style="display: block;"> <br> <br> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 10pt;"> <div
 style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> On Friday, February 7, 2014 12:36 PM, Andreas Schumacher <andreas@erlang.org> wrote:<br> </font> </div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;">  <div class="y_msg_container">We changed the version scheme for two reasons: For the first, we <br>abandoned the R-version scheme, since it has a meaning inside Ericsson <br>that differs from how we used it; that caused some confusion. Secondly, <br>we adapted a version scheme that allows us to bookkeep fine-grained <br>patches on arbitrary OTP versions to our customers with support agreements.<br><br>The new version scheme is *not* semantic versioning; although, it has <br>been inspired by it. We do not want to use semantic versioning (as <br>defined by <a
 href="http://semver.org/" target="_blank">http://semver.org/</a>) out of the box since it does not fit our <br>needs. Most importantly, we must be able branch out from any old version <br>and also be able to do so multiple times. This is not possible when <br>limited to only using MAJOR.MINOR.PATCH as version numbers. For example, <br>if we have released 17.0, 17.0.1, and 17.0.2 we may have to release a <br>patch based on 17.0.1. In this case it will be given the version 17.0.1.1.<br><br>A new MAJOR release is denoted with <X>.0, where <X> is incremented by <br>one at the delivery of a new major release, which may contain potential <br>incompatibilities.<br><br>A pre-release is denoted with <X>.0-rc<N>, where <N> starts with 1 at <br>the delivery of the first pre-release, and is incremented by one for <br>each subsequent pre-release. "-rc0" will be used during development up <br>to the first release candidate. Pre-releases
 <X>-rc<N> sort before <X>. <br>Apart from <X>-rc<N>, there are no plans for other special parts; <br>although that might change if the need arises.<br><br>A MINOR and/or PATCH (bug-fix) release is denoted with <X>.<Y>.<Z>, where:<br>- <Y> is set to 0 when <X> is incremented and is incremented by one when <br>new (minor)<br>   functionality is released. <Y> is used even when <Y> == 0.<br>- <Z> is set to 0 when <X> or <Y> is incremented, and incremented by one <br>when only bug<br>   fixes are released. <Z> is not used when <Z> == 0, unless [support <br>patches] patches are based on that version; see below.<br><br>Everything in a version V0 = <X>.<Y0>.<Z0> is included in a version V1 = <br><X>.<Y1>.<Z1> if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 <br>&& Z1 > Z0).<br><br>The OTP
 major release and the complete OTP version can be retrieved from <br>erlang code using the following:<br><br>    1> erlang:system_info(otp_release).<br>    "17"<br>    2> erlang:system_info(otp_correction_package).<br>    "17.0-rc1"<br><br>NOTE: The name of the argument "otp_correction_package" will be changed <br>to "otp_version." In addition, a corresponding flag "otp_version" will <br>be added to the erl command, in order to allow the extraction of the <br>complete version number from command line tools.<br><br>Version changes in applications imply a version change on OTP level, but <br>they are not propagated one-to-one; especially, a change of the major <br>version of an application does not necessarily imply a change of the <br>major version at the OTP level. The mapping is a case-by-case decision <br>that depends on the application, the type of functionality, impacts on <br>backward compatibility,
 etc.<br><br>It is basically only the releases of the form <X>.<Y>.<Z> that are of <br>interest for the Erlang open source community. However, from OTP 17.0 we <br>will only deliver source code releases [even to our customers with <br>support agreements]; and thus, even traces of support-patch <br>release-versions on top of those regular releases are going to be <br>visible in the public Erlang/OTP Git repository. The following is a <br>brief description of the format of those patch releases:<br><br>When branching out, we add ".1" at the end of <X>.<Y>.<Z>, unless this <br>version number has already been used. If it has already been used, we <br>search for an unused version number by adding more and more ".0" between <br>the version we are branching from, and the ".1" that we add at the end. <br>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 <br>all versions of modifications based on version
 17.0.1.<br><br>When basing a patch or a feature on an already branched version that do <br>not require any new branching, we increase the last part of the version.<br><br>When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, <br>you cannot<br>draw any conclusions about the specific modifications in the version, <br>but you can see what the modifications are based on.<br><br>The Erlang/OTP Team at Ericsson<br><br>_______________________________________________<br>erlang-questions mailing list<br><a ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br><br><br></div> </blockquote>  </div> </div>   </div> </div></body></html>