Erlang/OTP Release Cycle and Backwards Compatibility

Erlang/OTP follows a yearly rhythm: one major release every May, maintenance patch packages twice a year, and bug fixes for the two most recent major releases. The predictability suits the systems Erlang is used for, where uptime is measured in years and upgrades are planned well in advance. This article covers the release cadence, the version numbering, the compatibility guarantees, and how OTP releases relate to the languages built on the BEAM.

One major release a year

The OTP team at Ericsson ships a major release every May. OTP 26 arrived in May 2023, OTP 27 in May 2024 and OTP 28 in May 2025, with OTP 29 following the same pattern in 2026.

Between majors come maintenance patch packages, normally two per year, plus out-of-band releases when a security issue requires one.

Bug fixes go into the two most recent major releases. Older majors continue to work but receive nothing further, which in practice puts a two-year support window on any given OTP version.

Application versions versus OTP versions

Erlang/OTP is a collection of applications - stdlib, kernel, ssl, crypto, mnesia and dozens more

• each with its own version number. The OTP release number is the umbrella; the application versions underneath move independently.

This is why a changelog entry might read “ssl 11.2” rather than naming an OTP version, and why erlang:system_info(otp_release) and an application’s own version answer different questions. When reporting a bug or checking whether a fix applies, the application version is usually the relevant one.

The compatibility policy

Erlang’s compatibility approach is conservative in the places that matter for long-running systems:

• Source compatibility is maintained across majors in the large majority of cases. Removals happen, but only after a deprecation period spanning multiple releases.
• The distribution protocol between nodes generally supports one major version of difference, which is what makes rolling upgrades of a cluster possible.
• Hot code loading remains a first-class feature. A module can be replaced in a running system, with two versions of a module coexisting while processes migrate.
• BEAM file format changes can require recompilation when moving between majors, so dependencies should be rebuilt rather than reused.

For clusters, the practical rule is to upgrade one major at a time and to avoid mixing nodes more than one major apart.

Recent direction

Work across recent releases has tended towards developer experience and tooling rather than changes to the core runtime model:

• A built-in JSON module, removing a dependency that nearly every project previously added.
• Documentation attributes (-doc), which bring documentation into the language itself rather than leaving it to external tools.
• Triple-quoted strings and sigils, making multi-line text and binaries easier to write.
• Compiler and type checking improvements, including work towards stronger static analysis of Erlang code.
• Ongoing JIT work in the BeamAsm compiler, extending coverage across architectures.

-doc "Return the greeting for a given name.".
-spec greet(binary()) -> binary().
greet(Name) ->
    <<"Hello, ", Name/binary, "!">>.

OTP and the wider BEAM ecosystem

Elixir, Gleam and LFE all run on the BEAM and depend on the OTP release underneath them. Each publishes a compatibility matrix stating which OTP majors it supports. Because OTP ships in May and the languages on top of it need time to adapt, there is usually a gap of weeks or months before a new OTP is fully supported across the ecosystem.

For production systems, the sensible order is: wait for your language and its major libraries to declare support, then upgrade OTP, then upgrade the language.

Upgrade guidance

• Read the deprecations section. OTP announces removals well in advance; the deprecation list in one release is the removal list in a later one.
• Rebuild dependencies. Do not carry compiled artefacts across a major upgrade.
• Run Dialyzer after upgrading. Type specifications in OTP applications change between releases, and Dialyzer will surface mismatches.
• Upgrade clusters one major at a time, node by node, verifying distribution compatibility as you go.

Conclusion

Erlang/OTP’s release model is as steady as the systems it runs: one major release each May, patches twice a year, and fixes for the two most recent majors. Combined with a conservative compatibility policy and hot code loading, that makes upgrades a planned activity rather than a risk. Track the two-year support window, wait for the ecosystem above you, and upgrade one major at a time.