| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Cleanliness.
|
|
|
|
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.
|
|
Earlier the 'restart_application' upgrade instruction always cause the
application to be restarted as permanent. This could cause the system
to end up in an unexpected state after an upgrade. This is now
corrected.
|
|
It was possible to insert {Mod::atom(),Vsn::term()} instead of
Mod::atom() in the modules list in a .app file. This was not visible
in the documentation of .app files, but it was visible in the
documentation of application:load/[1,2] (where the .app file term can
be used directly as first argument).
The Vsn part was never used, so this possibility has now been removed.
|
|
|
|
Earlier, there was only one valid instruction to restart the emulator
in an appup/relup script, 'restart_new_emulator'. A new instuction,
'restart_emulator', is now added, and the meaning is as follows:
'restart_new_emulator' is mainly for the core applications (erts,
kernel, stdlib and sasl), and it indicates that there is new core
functionality in the release and the emulator needs to be restarted
before executing the upgrade scripts. If this instruction exists, a
temporary release will be created which consists of the new version
erts, kernel, stdlib and sasl, and the old versions of all other
applications. After restarting the emulator with this temporary
release, the rest of the upgrade instructions are executed, including
loading of new versions.
'restart_emulator' can be used by any application if a restart of the
emulator is needed after the upgrade instructions have been
executed. In this case, the emulator will be restarted with the new
release (i.e. not a tempoarary one) after all other upgrade
instructions for all applications have been excecuted.
|
|
|
