When building a release with Distillery (and more generally when building an Erlang release), there is a xxx.rel file defining all the applications the release depends on. In these dependencies, some OTP applications may be present.
If I build a release with Erlang 21.1, there is a ssl-9.0.2 application in the dependencies. If I run this release with Erlang 21.1.1, it won’t start because in this Erlang version there is ssl-9.0.3 and ssl-9.0.2 is not found. Nevertheless, according to Erlang’s documentation the OTP version in my case is just 21, the major number of the Erlang’s version. To my understanding this should mean that OTP is the same across all Erlang-21.X.Y versions… And I shouldn’t run into this issue.
I thought there were some backward compatibility rule for Erlang like "If it’s build with Erlang X it runs with Erlang X+2". Am I wrong?
This question comes from the fact that I built a release, without embedded erts, with Erlang 21.1 and tried to run it within a official Erlang 21.1 docker image… Which boils down to be really an Erlang 21.1.1 due to the way they manage their tags.
The compatibility guarantee is given for modules and code in .beam files - it’s not the same as having a release running on different versions.
A release is always built against a specific runtime version and can’t run on other versions. In particular, a part of the release is a “boot script” that is responsible for loading modules and applications that lists every single module to be loaded explicitly.
But I’m a bit disappointed: is there a way then to package .beam files in a way that they can be deployed on any compatible version of Erlang, without the release process limitation? Something like Java’s JAR file, that can be dropped on any compatible machine/VM/container with a compatible (in the wide sense) Erlang version and just run? Something that won’t require me re-inventing a release process?
Yes, there is a possibility: escripts, which I guess are similar in nature as a java .JAR file.
But it is important to realize that they are not the same as releases: Releases pin to very specific versions of the runtime, in part because it allows releases to perform hot-upgrades (and downgrades); that is, update the running executable without having to restart it. Obviously this is not possible with an escript.
Ok, thank you. Even if I’m not in the situation of having to perform upgrades/downgrades, escripts are not what I’m looking for.
So I understand that releases are really tied to an exact Erlang release version, beyond OTP versioning. So my takeaway is to tell the guys that produces the Erlang official releases to be more careful about that: Images tagged 21.1 and 21.1.1 are exactly the same, but should not.
