| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fix typos or minor faults.
Move out code listing of target_system.erl, and use codeinclude
statement to include this file from sasl/examples directory.
|
|
Changes to the mechanism for upgrading the emulator in OTP R15 was
erronously not handled in release_handler:upgrade_app, downgrade_app,
upgrade_script and downgrade_script. This has been corrected,
including test and documentation.
|
|
* siri/sasl/upgrade-erts/OTP-9438:
Fix bug in erts upgrade on windows
Add release vsn info to erts_vsn_changed warning
Check for sasl application in systools:make_script and make_relup
Add syntax check of relup to check_install_release and install_release
Add documentation for upgrade from pre R15 to post R15 sasl
Handle upgrade from pre R15 to post R15 sasl
Step version of sasl to 2.2 for R15
Document upgrade instructions restart_new_emulator and restart_emulator
Wait for two restarts in upgrade_restart test
Add restart_new_emulator instruction to kernel, stdlib and sasl appups
Distinguish restart_new_emulator from restart_emulator in upgrade instructions
Upgrade erts: merge sys.config for tmp release instead of using old
Allow regexp for version in .appup
Restart emulator before running upgrade script when erts is upgraded
Conflicts:
lib/sasl/src/release_handler.erl
lib/sasl/test/release_handler_SUITE.erl
|
|
New emulator upgrade mechanism introduced in R15 can only work if the
sasl version to upgrade from is 2.2 or later. I.e. if we are already
running at least R15.
This commit adds backwards compatiblity for upgrades from earlier
versions, meaning that the new code is loaded into the old emulator
and code_change is executed - then after all application code is
updated, the emulator is restarted with the new erts version.
Note that this might cause problems if the new code is compiled with
the new emulator and there have been updates to the beam format. If
this happens, the workaround is to compile the new code with the old
emulator.
|
|
|
|
This is an extension to which_releases that allows a user to specify the
status of the releases they wish to be returned. For instance it allows
for quickly determining which release is 'permanent' without the need of
parsing the entire release list.
|
|
Given this option, all modules that are to be purged by indicated
upgrade,and that can be soft purged, will be purged when all other
check of check_install_release have been successfully completed.
I added a note under install_release in the reference manual about how
to use check_install_release with this new option in order to speed up
the execution of install_release.
I also added three more test cases for this functionality.
|
|
This commit utilizes the new bif erlang:check_old_code/1 to check if a
module has old code in the system or not before running
erlang:check_process_code/2. This is to optimize
release_handler:install_release (and
release_handler:check_install_release).
A new test is added which checks that after traversing all
processes/modules once and purging all old code, the second run
through this part of the code is "sufficiently" much faster.
A note is also added in the reference manual for
release_handler:install_release about how to go around the efficiency
problem of this function.
|
|
|
