aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/src/systools_relup.erl
AgeCommit message (Collapse)Author
2011-11-18Merge branch 'siri/sasl/upgrade-erts/OTP-9438'Siri Hansen
* 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
2011-11-17Add release vsn info to erts_vsn_changed warningSiri Hansen
2011-11-17Check for sasl application in systools:make_script and make_relupSiri Hansen
make_script will give warning but allow it make_relup will fail since it is not possible to upgrade if sasl is not included in both releases.
2011-11-17Handle upgrade from pre R15 to post R15 saslSiri Hansen
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.
2011-11-17Add restart_new_emulator instruction to kernel, stdlib and sasl appupsSiri Hansen
The appup files for kernel, stdlib and sasl did not contain any UpFromVsn and DownToVsn. This means that it was not possible to create a relup file with systool:make_relup if any of these applications had changed. This commit adds entries in the appup files for a maximum of two major releases back - all with only one upgrade instruction: restart_new_emulator. The point is to allow relups to be generated, but ensure that no soft upgrade is done for these three applications - i.e. they will always cause a restart of the emulator prior to all other upgrade instructions from other applications. Test cases (appup_test) are added to kernel_SUITE, stdlib_SUITE and sasl_SUITE. These all check that expected versions are matched in the appups, and illegal versions (older than two major releases, or in any other way illegal) do not match. The test is written in a general way where it is assumed that the version of these applications are stepped according the the rule that major releases step the second number, maintenance releases step the third number and patches step the fourth number.
2011-11-17Distinguish restart_new_emulator from restart_emulator in upgrade instructionsSiri Hansen
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.
2011-11-17Allow regexp for version in .appupSiri Hansen
In order to avoid duplication of upgrade instructions in .appup files, we now allow regular expressions to specify the UpFrom and DownTo versions. To be considered a regular expression, the version identifier must be specified as a binary, e.g. <<"2\\.1\\.[0-9]+">> will match versions 2.1.x, where x is any number.
2011-11-17Restart emulator before running upgrade script when erts is upgradedSiri Hansen
If the version of erts differs between two releases, the release handler automatically adds a 'restart_new_emulator' instruction to the upgrade script (relup). Earlier, this instruction was always added at the end of the upgrade script, causing the following sequence of operations during an upgrade (a bit simplified): 1. suspend processes 2. load new code 3. execute code_change functions 4. resume processes 5. restart emulator with new erts version Obviously, this caused the new code to be loaded into the old emulator and this would fail if the beam format had been changed in the new version of the emulator. To overcome this problem, this commit changes the order of the instructions, so for upgrade with changed erts version we now have: 1. restart emulator with new erts, kernel, stdlib and sasl versions, but old versions of all other applications. 2. suspend processes 3. load new code 4. execute code_change functions 5. resume processes This is implemented by creating a temporary release, including new erts, kernel, stdlib and sasl from the new release and all other applications from the old release. A new boot file for this temporary release is created, which includes a new 'apply' instruction to run release_handler:new_emulator_upgrade/2. Then the emulator is restarted using this boot file - and release_handler:new_emulator_upgrade/2 executes the rest of the upgrade script. For downgrade, the order will be as before: 1. suspend processes 2. execute code_change functions with 'down'-indication 3. load old code 4. resume processes 5. restart emulator with old erts version
2011-09-08systools: add warnings_as_errors optionTuncer Ayaz
2011-03-30Change default behaviour to not check src code when creating releaseSiri Hansen
Add new option <c>src_tests</c> to systools:make_script and systools:make_tar. The old option <c>no_module_tests</c> is now ignored as this is the default behaviour.
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2011-02-25Honor start type in .rel files when building relup filesPaul Guyot
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).
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP