This document describes strategy regarding supported Releases, compatibility, deprecations and removal of functionality. This document was introduced in OTP 21. Actions taken regarding these issues before OTP 21 did not adhere this document.
In general, bugs are only fixed on the latest
Due to the above, pull requests are only accepted on the
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 nodes can communicate across at least two preceding and two subsequent releases.
Compiled code can be loaded on at least two subsequent releases.
Loading on previous releases is not supported.
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
Compatible between releases.
New warnings may be issued between releases.
Incompatible changes may occur between releases.
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:
It might be necessary to introduce incompatible changes in order to solve a security issue. This kind of incompatibility might occur in a patch.
We will not be bug-compatible. A bug fix might introduce incompatible changes. This kind of incompatibility might occur in a patch.
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.
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.
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.