System Principles

User's Guide

Version 10.3.5.19

• User's Guide
• PDF
• Top

• Expand All
• Contract All

Chapters

• System Principles
  • Top of chapter
  • Starting the System
  • Restarting and Stopping the System
  • Boot Scripts
  • Code Loading Strategy
  • File Types
• Error Logging
  • Top of chapter
  • Error Information From the Runtime System
  • Log events from OTP behaviours
• Creating and Upgrading a Target System
  • Top of chapter
  • Creating a Target System
  • Installing a Target System
  • Starting a Target System
  • System Configuration Parameters
  • Differences From the Install Script
  • Creating the Next Version
  • Upgrading the Target System
  • Listing of target_system.erl
• Upgrade when Erlang/OTP has Changed
  • Top of chapter
  • Introduction
  • Upgrade of Core Applications
  • Applications that Still do Not Allow Code Upgrade
• Versions
  • Top of chapter
  • OTP Version
  • Application Version
  • Version Scheme
  • Releases and Patches
  • OTP Versions Tree
  • OTP 17.0 Application Versions
• Support, Compatibility, Deprecations, and Removal
  • Top of chapter
  • Supported Releases
  • Compatibility
  • Deprecation
  • Removal

6 Support, Compatibility, Deprecations, and Removal

6.1  Supported Releases

In general, bugs are only fixed on the latest release, and new features are introduced in the upcoming release that is under development. However, when we, due to internal reasons, fix bugs on older releases, these will be available and announced as well.

Due to the above, pull requests are only accepted on the maint and the master branches in our git repository. The maint branch contains changes planned for the next maintenance patch package on the latest OTP release and the master branch contain changes planned for the upcoming OTP release.

6.2  Compatibility

We always strive to remain as compatible as possible even in the cases where we give no compatibility guarantees.

Different parts of the system will be handled differently regarding compatibility. The following items describe how different parts of the system are handled.

Erlang Distribution

Erlang nodes can communicate across at least two preceding and two subsequent releases.

Compiled BEAM Code, NIF Libraries and Drivers

Compiled code can be loaded on at least two subsequent releases.

Loading on previous releases is not supported.

Compiled HiPE Code

Compiled HiPE code can be loaded on the exact same build of ERTS that was used when compiling the code. It might however work on other builds, the emulator verifies checksums in order to determine if it can load the code or not. Note that HiPE has some limitations. For more information see the documentation of the HiPE application.

APIs

Compatible between releases.

Compiler Warnings

New warnings may be issued between releases.

Command Line Arguments

Incompatible changes may occur between releases.

OTP Build Procedures

Incompatible changes may occur between releases.

Under certain circumstances incompatible changes might be introduced even in parts of the system that should be compatible between releases. Things that might trigger incompatible changes like this are:

Security Issues

It might be necessary to introduce incompatible changes in order to solve a security issue. This kind of incompatibility might occur in a patch.

Bug Fixes

We will not be bug-compatible. A bug fix might introduce incompatible changes. This kind of incompatibility might occur in a patch.

Severe Previous Design Issues

Some parts of OTP were designed a very long time ago and did not necessarily take today's computing environments into account. In some cases the consequences of those design decisions are too severe. This may be performance wise, scalability wise, etc. If we deem the consequences too severe, we might introduce incompatible changes. This kind of incompatibility will not be introduced in a patch, but instead in the next release.

Peripheral, trace, and debug functionality is at greater risk of being changed in an incompatible way than functionality in the language itself and core libraries used during operation.

6.3  Deprecation

Functionality is deprecated when new functionality is introduced that is preferred to be used instead of the old functionality that is being deprecated. The deprecation does not imply removal of the functionality unless an upcoming removal is explicitly stated in the deprecation.

Deprecated functionality will be documented as deprecated, and compiler warnings will be issued, when appropriate, as early as possible. That is, the new preferred functionality will appear at the same time as the deprecation is issued. A new deprecation will at least be announced in a release note and the documentation.

6.4  Removal

Legacy solutions may eventually need to be removed. In such cases, they will be phased out on a long enough time period to give users the time to adapt. Before removal of functionality it will be deprecated at least during one release with an explicit announcement about the upcoming removal. A new deprecation will at least be announced in a release note and the documentation.

Peripheral, trace, and debug functionality is at greater risk of removal than functionality in the language itself and core libraries used during operation.