From e310677df7b3ce6506b35044abafcb507caa7e07 Mon Sep 17 00:00:00 2001 From: Rickard Green Date: Mon, 10 Mar 2014 17:44:25 +0100 Subject: Verify runtime_dependencies when running 'otp_build patch_app' --- system/doc/installation_guide/otp_version.xml | 96 --------- system/doc/installation_guide/part.xml | 1 - system/doc/installation_guide/xmlfiles.mk | 1 - system/doc/system_principles/part.xml | 1 + system/doc/system_principles/versions.xml | 267 ++++++++++++++++++++++++++ system/doc/system_principles/xmlfiles.mk | 3 +- 6 files changed, 270 insertions(+), 99 deletions(-) delete mode 100644 system/doc/installation_guide/otp_version.xml create mode 100644 system/doc/system_principles/versions.xml (limited to 'system/doc') diff --git a/system/doc/installation_guide/otp_version.xml b/system/doc/installation_guide/otp_version.xml deleted file mode 100644 index 0ce5144160..0000000000 --- a/system/doc/installation_guide/otp_version.xml +++ /dev/null @@ -1,96 +0,0 @@ - - - - -
- - 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.

- - diff --git a/system/doc/installation_guide/part.xml b/system/doc/installation_guide/part.xml index 150df39512..19808fd165 100644 --- a/system/doc/installation_guide/part.xml +++ b/system/doc/installation_guide/part.xml @@ -31,7 +31,6 @@

How to install Erlang/OTP on UNIX or Windows.

 - diff --git a/system/doc/installation_guide/xmlfiles.mk b/system/doc/installation_guide/xmlfiles.mk index 245491ab94..3995c607af 100644 --- a/system/doc/installation_guide/xmlfiles.mk +++ b/system/doc/installation_guide/xmlfiles.mk @@ -17,7 +17,6 @@ # %CopyrightEnd% # INST_GUIDE_CHAPTER_FILES = \ - otp_version.xml \ install-binary.xml \ verification.xml \ INSTALL.xml \ diff --git a/system/doc/system_principles/part.xml b/system/doc/system_principles/part.xml index 915d5aca9b..811428baae 100644 --- a/system/doc/system_principles/part.xml +++ b/system/doc/system_principles/part.xml @@ -31,5 +31,6 @@ + diff --git a/system/doc/system_principles/versions.xml b/system/doc/system_principles/versions.xml new file mode 100644 index 0000000000..6bfa9d1eed --- /dev/null +++ b/system/doc/system_principles/versions.xml @@ -0,0 +1,267 @@ + + + + +
+ + 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. + + + + Versions + + + + + + 2014-02-19 + + versions.xml +
+
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 + 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 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 white 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.

+

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

 + In which OTP version was kernel-3.0 introduced? +

$ 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.

 +
+
+ +
Application Version +

As of OTP 17.0 application versions will use the same + version scheme 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.

+
+ + +
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.

+
+
+ + +
OTP 17.0 Application Versions +

The following application versions were part of OTP 17.0. If + the normal part of an applications version number compares + as smaller than the corresponding application version in this list, + the version number does not adhere to the version scheme introduced + in OTP 17.0 and should be considered as not having an order against + versions used as of OTP 17.0.

+ + asn1-3.0 + common_test-1.8 + compiler-5.0 + cosEvent-2.1.15 + cosEventDomain-1.1.14 + cosFileTransfer-1.1.16 + cosNotification-1.1.21 + cosProperty-1.1.17 + cosTime-1.1.14 + cosTransactions-1.2.14 + crypto-3.3 + debugger-4.0 + dialyzer-2.7 + diameter-1.6 + edoc-0.7.13 + eldap-1.0.3 + erl_docgen-0.3.5 + erl_interface-3.7.16 + erts-6.0 + et-1.5 + eunit-2.2.7 + gs-1.5.16 + hipe-3.10.3 + ic-4.3.5 + inets-5.10 + jinterface-1.5.9 + kernel-3.0 + megaco-3.17.1 + mnesia-4.12 + observer-2.0 + odbc-2.10.20 + orber-3.6.27 + os_mon-2.2.15 + ose-1.0 + otp_mibs-1.0.9 + parsetools-2.0.11 + percept-0.8.9 + public_key-0.22 + reltool-0.6.5 + runtime_tools-1.8.14 + sasl-2.4 + snmp-4.25.1 + ssh-3.0.1 + ssl-5.3.4 + stdlib-2.0 + syntax_tools-1.6.14 + test_server-3.7 + tools-2.6.14 + typer-0.9.6 + webtool-0.8.10 + wx-1.2 + xmerl-1.3.7 + +
+ + diff --git a/system/doc/system_principles/xmlfiles.mk b/system/doc/system_principles/xmlfiles.mk index 4cbc00ed52..9743949798 100644 --- a/system/doc/system_principles/xmlfiles.mk +++ b/system/doc/system_principles/xmlfiles.mk @@ -19,4 +19,5 @@ SYSTEM_PRINCIPLES_CHAPTER_FILES = \ system_principles.xml \ error_logging.xml \ - create_target.xml + create_target.xml \ + versions.xml -- cgit v1.2.3