While building a upgrade package rebar will add new paths to the
internal erlang path, these paths and their order have effects on how
the package is built. This patch should fix some corner cases where a
user can receive a "undefined application" error.
While building an upgrade the sys.config file should be copied into the
upgrade tarball so release_handler:install_releases/1 does not clobber
the existing configuration from the application environment.
This patch corrects the vm.args behavior while building upgrade tarballs
by copying the file from the release into the upgrade. Additionally it
patches the dummy runner script in the upgrade test project to work
properly.
app.config has been a long standing erroneous file in rebar. Erlang/OTP
documentation suggests a sys.config file instead. This file is stored in
the releases/VSN directory. This does a few things but most importantly
it ensures your config (contained in the application environment)
survives a hot upgrade. It also has the advantage of allowing the
configuration of the application to be versioned along side the
application code. This patch flips rebar to use sys.config rather than
app.config.
Additionally it makes this flip to vm.args as well, making them
versioned just like sys.config.
This patch also includes runner script changes to support the old
etc/app.config config file location and support for Windows.
Thanks to mokele for the initial work and kick in the pants to make this
finially happen.
The target_dir config in reltool allows you to put your release in
a directory other than in ./NAME, so we should look in the parent
directory of that to find the new and old versions instead of
simply looking in ./
Move untaring and retaring into a temporary path instead of in ./
to prevent name collisions with "releases" and "lib" that might
exist already. Having a subdirectory rel/releases/ can be useful.
To support OTP release upgrades I have added support for building
upgrade packages. Support for this is included in the
rebar_upgrade module, specifically generate_upgrade/2. It requires
one variable to be set on the command line 'previous_release' which
is the absolute path or relative path from 'rel/' to the previous
release one is upgrading from. Running an upgrade will create the
needed files, including a relup and result in a tarball containing
the upgrade being written to 'rel/'. When done it cleans up the
temporary files systools created.
Usage:
$ rebar generate-upgrade previous_release=/path/to/old/version
This also includes a dummy application that can be used to test
upgrades as well as an example.
Special thanks to Daniel Reverri, Jesper Louis Andersen and
Richard Jones for comments and patches.
