aboutsummaryrefslogblamecommitdiffstats
path: root/system/doc/system_principles/misc.xml
blob: dd6c2a133660b50b114512889e1a492ba0e415c6 (plain) (tree)





































































































































































































                                                                                         
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>2018</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at
 
          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions and
      limitations under the License.
    
    </legalnotice>

    <title>Support, Compatibility, Deprecations, and Removal</title>
    <prepared></prepared>
    <responsible></responsible>
    <docno></docno>
    <approved></approved>
    <checked></checked>
    <date>2018-05-21</date>
    <rev></rev>
    <file>misc.xml</file>
  </header>

  <section>
    <marker id="supported_releases"/>
    <title>Supported Releases</title>
    <p>
      In general, bugs are only fixed on the latest
      <seealso marker="versions#releases_and_patches">release</seealso>,
      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.
    </p>
    <p>
      Due to the above, pull requests are only accepted on the
      <c>maint</c> and the <c>master</c> branches in our
      <url href="https://github.com/erlang/otp">git repository</url>.
      The <c>maint</c> branch contains changes planned for the next
      <seealso marker="versions#releases_and_patches">maintenance patch package</seealso>
      on the latest OTP release and the <c>master</c> branch contain
      changes planned for the upcoming OTP release.
    </p>
  </section>

  <section>
    <marker id="compatibility"/>
    <title>Compatibility</title>
    <p>
      We always strive to remain as compatible as possible
      even in the cases where we give no compatibility guarantees.
    </p>
    <p>
      Different parts of the system will be handled differently
      regarding compatibility. The following items describe how
      different parts of the system are handled.
    </p>
    <taglist>
      <tag>Erlang Distribution</tag>
      <item>
	<p>
	  Erlang nodes can communicate across at least
	  two preceding and two subsequent releases.
	</p>
      </item>
      <tag>Compiled BEAM Code, NIF Libraries and Drivers</tag>
      <item>
	<p>
	  Compiled code can be loaded on at least two
	  subsequent releases.
	</p>
	<p>
	  Loading on previous releases is <em>not</em> supported.
	</p>
      </item>
      <tag>Compiled HiPE Code</tag>
      <item>
	<p>
	  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
	  <seealso marker="hipe:HiPE_app">HiPE</seealso> application.
	</p>
      </item>
      <tag>APIs</tag>
      <item>
	<p>Compatible between releases.</p>
      </item>
      <tag>Compiler Warnings</tag>
      <item>
	<p>New warnings may be issued between releases.</p>
      </item>
      <tag>Command Line Arguments</tag>
      <item>
	<p>Incompatible changes may occur between releases.</p>
      </item>
      <tag>OTP Build Procedures</tag>
      <item><p>Incompatible changes may occur between releases.</p></item>
    </taglist>
    <p>
      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:
    </p>
    <taglist>
      <tag>Security Issues</tag>
      <item>
	<p>
	  It might be necessary to introduce incompatible changes
	  in order to solve a security issue. This kind of
	  incompatibility might occur in a patch.
	</p>
      </item>
      <tag>Bug Fixes</tag>
      <item>
	<p>
	  We will not be bug-compatible. A bug fix might introduce
	  incompatible changes. This kind of incompatibility
	  might occur in a patch.
	</p>
      </item>
      <tag>Severe Previous Design Issues</tag>
      <item>
	<p>
	  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.
	</p>
      </item>
    </taglist>
    <p>
      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.
    </p>
  </section>

  <section>
    <marker id="deprecation"/>
    <title>Deprecation</title>
    <p>
      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 <em>not</em> imply removal of the functionality unless
      an upcoming removal is explicitly stated in the deprecation.
    </p>
    <p>
      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.
    </p>
  </section>

  <section>
    <marker id="removal"/>
    <title>Removal</title>
    <p>
      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.
    </p>
    <p>
      Peripheral, trace, and debug functionality is at greater
      risk of removal than functionality in the language itself
      and core libraries used during operation.
    </p>
  </section>

</chapter>