MS Windows build use of versions in directory names/paths

[Frank Seesink]

I'm relatively new to Erlang, so please excuse me if this has been
covered.  I've searched the FAQs and not found a reasoning, so thought I
would post here.

What exactly is the reasoning behind using version numbers in the
directory names/paths in the Windows prebuilt binaries?  That is, the
latest version of Erlang as I write this is Erlang/OTP R10B-4 (release
23 Mar 2005).  Performing a vanilla/standard install, the user has
Erland installed in

	x:\Program Files\erl5.4.5

and there is a subdirectory

	x:\Program Files\erl5.4.5\erts-5.4.5

Why does the Erlang development team (or the Windows installer creator)
just install to

	x:\Program Files\erl\

with a subdirectory

	x:\Program Files\erl\erts
?

Here is why I ask.  I notice that often open source apps do this sort of
thing, especially when they have ties to the *nix world.  I also know
that in the *nix world, it is common to decompress appX version A.B.C in
a directory such as ./appX-A.B.C, then create a symlink

	./app-X -> ./appX-A.B.C

This allows the path to the application to remain constant, regardless
of updates/changes.  If appX version A.B.D comes out, that is simply
decompressed to its own folder and the 'app-X' symlink changed to point
to the new version.

However, this is not how things are done typically in the Windows world.
  I've gotten used to certain open source projects installing in a
different directory with reach version release.  For example, the game
BZFlag v2.0.0 installed in

	x:\Program Files\BZFlag2.0.0

whereas BZFlag 2.0.2 installed in

	x:\Program Files\BZFlag2.0.2

This is annoying enough, as my personal firewall rules must be adjusted
with each release.  Average Windows users will not deal with this well,
as it gets to be quite annoying.  But this is tolerable with games as
you typically do not build/layer other applications on top of them.

However, programming languages like Erlang exist almost exclusively for
just that reason:  to layer other applications on top of them.  Other
examples might be Perl, PHP, etc.  Now in the Windows world, one of the
most common variants of Perl is ActiveState's ActivePerl, and their
installer by default will install Perl in

	x:\Perl

The documentation on PHP similary advocates installing in a directory
such as

	x:\PHP

And with a new version release, updating is simply a matter of replacing
the old files with the new ones in most cases (barring those users who
heavily customize/add/change/delete files from the distribution).

The advantage of this approach is that the PATH to a given language's
files/engine remains the same.  This makes script writing easier, not to
mention the above firewall rule situation where you have
application-level firewalling.  There is no "moving target" as it were.

This issue came up for me as my introduction to Erlang came from looking
into ejabberd, the Erlang-based Jabber/XMPP server
(http://ejabberd.jabber.ru).  Installing/running ejabberd requires
Erlang, of course.  And the ejabberd installer offers to create a
Windows service so that a user can run ejabberd on system startup.

However, the installation of this NT service involves launching Erlang
and having it fire up ejabberd.  This, of course, necessitates putting
the PATH to the current installed version of Erlang into the appropriate
place in the Windows Registry
(HKLM\SYSTEM\CurrentControlSet\Services\ejabberd...) where the NT
service is set.  (Note this is not something many users will understand.)

If a new version of Windows software comes out, most people simply
either run the latest installer on top of the old install, OR often they
will first uninstall the old version before installing the new one.  I
tend to do the latter so not sure how well the former might avoid this.
  That is, if I install R10B-4 on top of R10B-3, I'm not sure if it will
simply keep the current path or not.

But using the "uninstall, then install" approach results in a lot of
things suddenly breaking.  The ejabberd service is no longer pointing to
the right directory for Erlang.  Any scripts or other items which also
required this path are also snafu'd.  Note this does NOT happen with
updates to Perl or PHP, for example.

So I was wondering why the Erlang team chose this approach.  Noting that
many other open source projects do NOT resort to this in Windows by
default--e.g., Apache1/2 webservers, AWStats, Dev-PHP, Ethereal,
FeedReader, FileZilla/Server, Neverball, OpenSSL, PuTTY, WinMerge--it
seems it might be best NOT to put a version number in the path, but
rather let the user find the version either by looking at a README in
the installed directory, or in the case of Erlang, simply by running the
  shell.  Especially noting that updating Erlang itself at present can
result in almost ANY Erlang app breaking, and that the number of Erlang
apps will be >= 1 (otherwise why install Erlang?), this means with each
release of Erlang, users may have to go through and not just install the
latest Erlang, but they will have to go adjusting any and all Erlang
apps such as ejabberd which need the path information to work properly.

Thanks for any insight into this.  At present I resort to digging
through the system and adjusting the path where necessary, but I can
assure you that most Windows users will NOT do this.  The end result is
that adoption of Erlang as a language--just as I started playing due to
ejabberd--will be hindered as others may be frustrated/annoyed by this
process (and I believe rightfully so).  I know the folks behind ejabberd
swear by Erlang, and it definitely has some interesting features.  But
even their image will be tarnished any time someone updates Erlang only
to find that suddenly ejabberd will not run anymore.

P.S.	I tried adjusting the install path for Erlang, but the best I could
get was

	x:\Program Files\erl

Unfortunately, the subdirectory for ERTS is still

	x:\Program Files\erl\erts-5.4.5

And as ejabberd uses this path, BOOM!