Menu
I've noticed Erlang releases with version numbers like R13B04, R14B, R15A, etc. What do each of the release number components mean? Can one infer anything about API changes based on the version numbers? For example, does an upgrade from R13 to R14 imply backwards incompatible API changes?
258
Erlang/OTP 23.3 is the third and final maintenance patch package for OTP 23, with mostly bug fixes as well as a few improvements. A full list of bug fixes and improvements in the readme.
Erlang/OTP 22 is a new major release with new features and improvements as well as incompatibilities. For a deeper dive into the highlights of the OTP 22 release, you can read our blog here: http://blog.erlang.org/OTP-22-Highlights/
1 BeamAsm, the Erlang JIT. BeamAsm provides load-time conversion of Erlang BEAM instructions into native code on x86-64 and aarch64. This allows the loader to eliminate any instruction dispatching overhead and also specialize each instruction on their argument types.
The latest version of Erlang/OTP is 25.0. 3.
For example R14B04. R stands for Erlang/OPT Release. 14 is major version number. B stands for stable release (A is development/unstable). 04 is fourth minor version, i.e. fourth bugfix release in given major release. BEAM files and Erlang distribution protocol (ei) should always be compatible across two major version numbers. I.e. with current R14B04 instalation you should be able run .beam files compiled in R12 versions and R12 nodes should be able communicate with your new R14 nodes. API changes are much more conservative so you usually can be able compile and run source code from R7 ;-) Anyway experimental modules API can change even in minor version what happen in R13 with binary module if memory serves me right, but this really can happen only for experimental, unsupported or undocumented features.
68
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
