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

[Rickard Green]

On Fri, Feb 7, 2014 at 5:36 PM, Thomas Lindgren
<thomasl_erlang@REDACTED> wrote:
>
>
> "    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.


The reason to why they are as they are, and in my opinion should
remain so follow below. I should say that we've had lots of different
opinions about this at OTP.

A brief history of how OTP releases have been named. Prior to R13B,
OTP release names used to be a number in between an R and a B (with a
few exceptions that I'll for simplicity ignore since they won't effect
the reasoning). At first the open-source community got access to the
R<N>B release and nothing more until R<N+1>B was released.

At some point we began publishing the latest patch level more
frequently to the open-source community. If I remember correct, this
was during the R10B release. In order to keep these open-source
tar-balls apart we added a "-<X>" behind the release name, where <X>
was an integer counter incremented for each tar-ball put up on the
web-site. During R10B we published 11 tar-balls R10B, R10B-1, ...,
R10B-10. One R10B plain without patches and 10 R10B with snapshots of
different patch levels. Each and every one containing the latest R10B
patch level when they were published. All of them containing the OTP
*R10B* release at different patch levels.

As of R13B we switched from publishing tar-balls at different
patch-levels to actually introducing minor releases R13B01, R13B02,
... This was not just a switch in naming convention. We actually
released new releases which is an important point. For example, the
R13B01 release name was exposed in start scripts, etc.

As of OTP 17 we kind of go back to how it used to be before R13B, but
we drop the R and the B. When we publish new tar-balls (and tags in
git) after the plain release it will not be a new release, but instead
a snapshot of a patch level. A major point of doing this change is to
get rid of these minor releases as true releases. I won't go into why
since this text is long as it is anyway.

Internally at Ericsson we have a sequence of patch numbers that we use
in order to identify a specific patch. This sequence span all
releases. When we publish a patch on an application of a specific
release this patch number is incremented. For example, patch number
874 is a patch level on R11B and 916 is a patch level on R10B. The
only conclusion you can draw from the patch level number is which
patch was first published. In R10B we did not expose this patch level
number but instead gave the tar-ball yet another number (-<X>).

As of OTP 17 we drop this patch level number sequence and start using
one set of patch level numbers per release. The patch level is not
expressed as an integer as it used to be, but instead as a version
number <X>.<Y>.<Z>[.<N> ...], for example, 17.0.1. This way the patch
level gives you a bit more information. You can for example see
directly which OTP release it applies to. This patch level version
number also replace the -<X> tar-ball naming scheme.

That is, the release that we soon are about to release is OTP 17, not
OTP 17.0. OTP 17.0 is a patch level identifier that in this case
happens to identify the OTP 17 plain release. When/If OTP 17.6.1 is
published, it is still the OTP 17 release, but with a different patch
level.

Since you today can fetch stuff directly from git you may stumble
across OTP patch levels that have not been publicly announced. If you
build and install such a system. You can then later, by looking at the
OTP patch level, get a feeling of how it relate to the publicly
announced patch levels.

Now to my point. If erlang:system_info(otp_release) is supposed to
behave as it always have behaved (which I think it should) it should
return the release name (as a string) and not the patch level. That
is, it should during the following release return "17", and nothing
else.

Previously we have not had an erlang:system_info() argument giving you
the patch level. The
erlang:system_info(otp_correction_package)/erlang:system_info(otp_version)
is a new argument, and is intended to give you the patch level that we
currently are on. (See the documentation of otp_correction_package for
further information)

That is, when the OTP 17 plain release is published
erlang:system_info(otp_correction_package)/erlang:system_info(otp_version)
will return "17.0". When/if patch level 17.6.1 is published
erlang:system_info(otp_release) will still return "17", but
erlang:system_info(otp_correction_package)/erlang:system_info(otp_version)
will return "17.6.1".


Sorry for the long text. It was way shorter in my head :-/

>
>
> (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?)


I think using the otp_ prefix is exactly what we want. If I start
releasing Erlang/RG think I should badarg on
erlang:system_info(otp_release), and return something useful from
erlang:system_info(rg_release) instead.


Regards,
Rickard Green, Erlang/OTP, Ericsson AB