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

[Vlad Dumitrescu]

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