Erlang releases can be versioned too, but how you do so depends on what tool(s) you use to generate releases. With reltool
and rebar
for example, you specify release versions in the reltool.config
file. For example, for a release named myrel
the top of its reltool.config
might appear as shown below:
{sys, [
{lib_dirs, []},
{erts, [{mod_cond, derived}, {app_file, strip}]},
{app_file, strip},
{rel, "myrel", "1.9",
...
The "1.9" shown in the {rel, "myrel", "1.9"
line is the release version number.
Alternatively, with systools
, a .script
file, which can be used to generate a .boot
file to specify how to load and start an Erlang system, contains the tuple {script, {ReleaseName, ReleaseVsn}, Actions}
where ReleaseVsn
specifies the release version. For example, the top of myrel.script
might look like this:
{script,
{"myrel","1.9"},
[{preLoaded,
[erl_prim_loader,erlang,erts_internal,init,otp_ring0,prim_eval,
prim_file,prim_inet,prim_zip,zlib]},
{progress,preloaded},
...
You could write such a file yourself, or more sensibly generate one with systools:make_script
from a release resource file, which generally has a .rel
suffix and the top of which specifies a release version as shown below:
{release, {RelName,Vsn}, {erts, EVsn},
...
where Vsn
is the release version and EVsn
is the version of the Erlang Runtime System (erts) the release should use.
With relx
, release versions are specified much as they are for .rel
files. See the relx documentation for details.