CVS, -vsn(), .app

[Ulf Wiger]

On 31 Jan 2002, Hal Snyder wrote:

>We're working on a release system for our OTP modules using the
>"$SECOND_ROOT" capability mentioned in section 3 of the sasl:systools
>manual. So far, all is going well, but there are a few questions
>relating to module versions in the .app file.
>
>1. The CVS $Revision$ tag is as close as we can get (easily) to a pure
>version control rev number in a .erl. It is autoexpanded to, e.g.:
>
>-vsn("$Revision: 1.7 $").
>
>Will this sort of version attribute in a module break anything?

If you look in the source files of the recent Erlang/OTP
releases, the -vsn() tag has been removed. The (main) reason for
this is that having automatically updated tags in the source code
would cause problems for the ClearCase merge facility. Basically,
a manual merge was always needed, if only due to the fact that
the -vsn() and -date() tags differed.


>2. It would be nice to grab the vsn attributes from freshly
>made .beam files and use them to cook myapp.app from
>myapp.app.src. Is there a tool somewhere in OTP (did I miss
>it?) that allows one to pull the vsn attribute out of a .beam?

You can always call Module:module_info(attributes), and extract
the version attribute (if there is one there).

>3. It seems version tagging of modules in the .app is not used
>in the releas of otp_src_R8B. Is there some reason we should
>not be using this feature?

Actually, the {Module, Vsn} format was the only one allowed in
the beginning, but since we at AXD 301 had (and still have)
automatically generated -vsn() attributes, we felt that it was
very cumbersome to manually update the .app files every time.
Thus, OTP introduced the alternative format of only listing the
module name. Now, since OTP has dropped the use of -vsn()
attributes themselves, my guess is that they didn't feel the need
to keep the original format anymore.

Also, since you can load modules from a patch directory, you're
bound to end up with inconsistencies between the versions listed
in the .app file and the -vsn() attribute (if any) in the .beam.

Personally, I think removing the -vsn() attribute was a sound
decision.

/Uffe