0
votes

Is there any way to version/tag an erlang project?

So far I've been using git tags to state my version releases, and a custom field in my application's config (eg {version, "0.0.1-alpha"}). But is there any better way to achieve this?

I am using rebar, I've looked up but I couldn't find such a feature. I know rebar works perfect with git tags, but I would also like to state the version/release in a config that will accompany my project's files.

In extend I would like to include that "package-config" in my application.

Cheers.

1

1 Answers

2
votes

Versions exist at several levels in Erlang:

  • Erlang modules can be versioned using the -vsn attribute. For example, the top of a mymodule.erl file might be written as shown below:

    -module(mymodule).
    -vsn(1.0).
    ...
    

    If you don't specify -vsn the Erlang compiler generates one for you using the MD5 checksum of the module file's contents.

  • Erlang applications are versioned in their .app files. For example, for an application named myapp, the top of its myapp.app might appear as shown below:

    {application,myapp,
        [{description,"My Favorite Application"},
        {vsn, "1.2.3"},
        ...
    
  • 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.

Erlang projects are therefore composed of a number of versioned entities, some of which might be under your control but others you might inherit via dependencies from other libraries/applications, including those from Erlang's standard libraries.