2014 Ericsson AB. All Rights Reserved. The contents of this file are subject to the Erlang Public License, Version 1.1, (the "License"); you may not use this file except in compliance with the License. You should have received a copy of the Erlang Public License along with this software. If not, it can be retrieved online at http://www.erlang.org/. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. OTP version 2014-02-19 otp_version.xml

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. In the normal case, the OTP 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 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. Release candidates have an -rc<N> suffix. The suffix -rc0 will be used during development up to the first release candidate.

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.

Application versions will be managed the same way as the OTP version. Application versions part of a release candidate will however not have an -rc<N> suffix as the OTP version. Also note that a major increment in an application version does not necessarily imply a major increment of the OTP version. This depends on whether the major change in the application is considered as a major change for OTP as a whole or not.

In an OTP source code tree as well as in an installed OTP development system, the OTP version can be read from the text file OTP_VERSION in the OTP installation root directory (code:root_dir()).

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.

On a target system (see the system principles documentation) no OTP_VERSION file will exist. This since one easily can create a target system where it is hard to even determine the base OTP version.