| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It is now explicitly stated that if the application type is `load`, the
application will not actually be restarted by the `restart_application`
instruction in relup, even if it is currently running. It will only be stopped
and re-loaded.
|
|
Fix some older errors as well.
|
|
|
|
|
|
|
|
The upgrade instruction 'remove_module' was added in OTP R7B (and
possibly in a patch in R5B or R6B, ticket OTP-3477), and translates to
the low level instruction 'remove', but adds the parameter DepMods
(modules on which Mod is dependent). The ticket says that
"remove_module should be added for symmetry with the add_module
instruction". remove_module was never documented or tested, and it was
never mentioned in a release note. It therefore seems to be low risk
in removing it.
The correct instruction to use when removing a module is
{delete_module,Mod}
which was added in OTP R10B and which is also documented and
tested. This translates to low level instructions 'remove' and 'purge'
i.e. the module is brutally purged after setting the current code to
old. This hardcoded brutal purge is the reason why PrePurge and
PostPurge parameters can not be given with the delete_module
instruction.
The parameter DepMods which was inclued in the remove_module
instruction does not exist for delete_module. From the documentation's
point of view, this is the same for add_module, and thus the two
instructions {add_module,Mod} and {delete_module,Mod} are now
symmetric. However, in the code there is a second instruction for
adding a module, {add_module,Mod,DepMods}, which is not documented. To
add symmetry even for this, {delete_module,Mod,DepMods} is now also
added. Documentation is added for all instructions.
|
|
In ref man for appup and in system documentation, design prinsiples,
add a warning related to upgrade when version of erts, kernel, stdlib
or sasl is changed. This will cause an emulator restart where new
version of emulator and core applications will startup together with
old versions of other applications. Care must be taken to avoid
problems due to backwards incompatibility.
|
|
|
|
|
|
|
|
|
|
|
|
Previously, relup file always included an
application:start(Application, permanent) apply instruction for every
application that appear in the UpTo/DowFrom release file, whatever
their start type in the release file.
The new implementation fixes this bug by honoring the start type
according to the rel(5) format. If the start type is none, no apply
line is included in the relup. If the start type is load, the relup
includes instruction to only load the application. Otherwise, the
relup includes an instruction to start the application to the
according type.
The fix is implemented by adding a new parameter to the
add_application high level appup instruction. This new parameter is
documented in appup(5).
|
|
|
