OTP Version
As of OTP release 17, the OTP release number corresponds to
the major part of the OTP version. The OTP version as a concept was
introduced in OTP 17. The version
scheme used is described in more detail below.
OTP of a specific version is a set of applications of specific
versions. The application versions identified by an OTP version
corresponds to application versions that have been tested together
by the Erlang/OTP team at Ericsson AB. An OTP system can however be
put together with applications from different OTP versions. Such a
combination of application versions has not been tested by the
Erlang/OTP team. It is therefore always preferred to use OTP
applications from one single OTP version.
Release candidates have an -rc<N>
suffix. The suffix -rc0 will be used during development up to
the first release candidate.
Retrieving Current OTP Version
In an OTP source code tree, the OTP version can be read from
the text file <OTP source root>/OTP_VERSION. The
absolute path to the file can be constructed by calling
filename:join([code:root_dir(), "OTP_VERSION"]).
In an installed OTP development system, the OTP version can be read
from the text file <OTP installation root>/releases/<OTP release number>/OTP_VERSION.
The absolute path to the file can by constructed by calling
filename:join([code:root_dir(), "releases", erlang:system_info(otp_release), "OTP_VERSION"]).
If the version read from the OTP_VERSION file in a
development system has a ** suffix, the system has been
patched using the
$ERL_TOP/otp_build patch_app
tool. In this case, the system consists of application versions from
multiple OTP versions. The version preceding the **
suffix corresponds to the OTP version of the base system that
has been patched. Note that if a development system is updated by
other means than $ERL_TOP/otp_build patch_app, the
OTP_VERSION file may identify wrong OTP version.
No OTP_VERSION file will be placed in a
target system created
by OTP tools. This since one easily can create a target system
where it is hard to even determine the base OTP version. You may,
however, place such a file there yourself if you know the OTP
version.
OTP Versions Table
The text file <OTP source root>/otp_versions.table that
is part of the source code contains information about all OTP versions
from OTP 17.0 up to current OTP version. Each line contains information
about application versions that are part of a specific OTP version, and
is on the format:
<OtpVersion> : <ChangedAppVersions> # <UnchangedAppVersions> :
<OtpVersion> is on the format OTP-<VSN>, i.e.,
the same as the git tag used to identify the source.
<ChangedAppVersions> and <UnchangedAppVersions>
are space separated lists of application versions on the
format <application>-<vsn>.
<ChangedAppVersions> corresponds to changed applications
with new version numbers in this OTP version, and
<UnchangedAppVersions> corresponds to unchanged application
versions in this OTP version. Both of them might be empty, although
not at the same time. If <ChangedAppVersions> is empty, no changes
has been made that change the build result of any application. This could
for example be a pure bug fix of the build system. The order of lines
is undefined. All white space characters in this file are either space
(character 32) or line-break (character 10).
Using ordinary UNIX tools like sed and grep one
can easily find answers to various questions like:
Which OTP versions are kernel-3.0 part of?
$ grep ' kernel-3\.0 ' otp_versions.table
$ sed 's/#.*//;/ kernel-3\.0 /!d' otp_versions.table
The above commands give a bit more information than the exact answers,
but adequate information when manually searching for answers to these
questions.
The format of the otp_versions.table might be subject
to changes during the OTP 17 release.
Version Scheme
Note that the version scheme was changed as of OTP 17.0. This implies
that application versions used prior to OTP 17.0 do not adhere to this
version scheme. A list of
application versions used in OTP 17.0 can be found
at the end of this document.
In the normal case, a version will be constructed as
<Major>.<Minor>.<Patch> where <Major>
is the most significant part. However, more dot separated parts than
this may exist. The dot separated parts consists of non-negative integers.
If all parts less significant than <Minor> equals 0,
they are omitted. The three normal parts
<Major>.<Minor>.<Patch> will be changed as
follows:
<Major>- Increased when major changes,
including incompatibilities, have been made.
<Minor>- Increased when new functionality
has been added.
<Patch>- Increased when pure bug fixes
have been made.
When a part in the version number is increased, all less significant
parts are set to 0.
An application version or an OTP version identifies source code
versions. That is, it does not imply anything about how the application
or OTP has been built.
Order of Versions
Version numbers in general are only partially ordered. However,
normal version numbers (with three parts) as of OTP 17.0 have a total
or linear order. This applies both to normal OTP versions and
normal application versions.
When comparing two version numbers that have an order, one
compare each part as ordinary integers from the most
significant part towards less significant parts. The order is
defined by the first parts of the same significance that
differ. An OTP version with a larger version include all
changes that that are part of a smaller OTP version. The same
goes for application versions.
In the general case, versions may have more than three parts. In
this case the versions are only partially ordered. Note that such
versions are only used in exceptional cases. When an extra
part (out of the normal three parts) is added to a version number,
a new branch of versions is made. The new branch has a linear
order against the base version. However, versions on different
branches have no order. Since they have no order, we
only know that they all include what is included in their
closest common ancestor. When branching multiple times from the
same base version, 0 parts are added between the base
version and the least significant 1 part until a unique
version is found. Versions that have an order can be compared
as described in the paragraph above.
An example of branched versions: The version 6.0.2.1
is a branched version from the base version 6.0.2.
Versions on the form 6.0.2.<X> can be compared
with normal versions smaller than or equal to 6.0.2,
and other versions on the form 6.0.2.<X>. The
version 6.0.2.1 will include all changes in
6.0.2. However, 6.0.3 will most likely
not include all changes in 6.0.2.1 (note that
these versions have no order). A second branched version from the base
version 6.0.2 will be version 6.0.2.0.1, and a
third branched version will be 6.0.2.0.0.1.