From 8eb20d1fb0eb3a3b96d5e80e2e2617f893ef6986 Mon Sep 17 00:00:00 2001
From: Siri Hansen
Date: Thu, 20 Feb 2014 16:45:28 +0100
Subject: Add info about upgrade of core applications
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.
---
lib/sasl/doc/src/appup.xml | 23 ++++++++++++++++++++---
system/doc/design_principles/release_handling.xml | 17 +++++++++++++++--
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/lib/sasl/doc/src/appup.xml b/lib/sasl/doc/src/appup.xml
index 85fcbed3ba..95f315d269 100644
--- a/lib/sasl/doc/src/appup.xml
+++ b/lib/sasl/doc/src/appup.xml
@@ -4,7 +4,7 @@
- 19972013
+ 19972014
Ericsson AB. All Rights Reserved.
@@ -84,6 +84,9 @@
version identifier must be specified as a binary, e.g.
<<"2\\.1\\.[0-9]+">>
will match all versions 2.1.x, where x is any number.
+ Note that the regular expression must match the complete
+ version string, so the above example will work for for
+ e.g. 2.1.1, but not for 2.1.1.1
@@ -339,7 +342,7 @@ restart_new_emulator
version of erts, kernel, stdlib and sasl are used when the
emulator restarts. Only one restart_new_emulator
instruction is allowed in the relup, and it shall be placed
- first. systools:make_relup3,4
+ first. systools:make_relup/3,4
will ensure this when the relup is generated. The rest of the
relup script is executed after the restart as a part of the boot
script.
@@ -347,11 +350,25 @@ restart_new_emulator
completed. To programatically find out if the upgrade is
complete,
call
- release_handler:which_releases and check if the
+ release_handler:which_releases/0,1 and check if the
expected release has status current.
The new release must still be made permanent after the upgrade
is completed. Otherwise, the old emulator is started in case of
an emulator restart.
+
+ As stated above, the restart_new_emulator
+ instruction causes the emulator to be restarted with new
+ versions of erts, kernel, stdlib and
+ sasl. All other applications, however, will at startup
+ be running their old versions in this new emulator. In most
+ cases this is no problem, but every now and then there will be
+ incompatible changes to the core applications which may cause
+ trouble in this setting. Such incompatible changes (when
+ functions are removed) are normally preceded by a deprecation
+ over two major releases. To make sure your application is not
+ crashed by an incompatible change, always remove any call to
+ deprecated functions as soon as possible.
+
restart_emulator
diff --git a/system/doc/design_principles/release_handling.xml b/system/doc/design_principles/release_handling.xml
index 2a5831b89f..ba8a88d1c2 100644
--- a/system/doc/design_principles/release_handling.xml
+++ b/system/doc/design_principles/release_handling.xml
@@ -4,7 +4,7 @@
- 20032013
+ 20032014
Ericsson AB. All Rights Reserved.
@@ -329,13 +329,26 @@
automatically ensured.
When the release handler encounters the instruction, it first
generates a temporary boot file, which starts the new versions
- of the emulator and the core applications. Then it shuts down
+ of the emulator and the core applications, and the old version
+ of all other applications. Then it shuts down
the current emulator by calling init:reboot(), see
init(3). All processes are terminated gracefully and
the system is rebooted by the heart program, using the
temporary boot file. After the reboot, the rest of the relup
instructions are executed. This is done as a part of the
temporary boot script.
+
+ Since this mechanism causes the new versions of the
+ emulator and core applications to run with the old version of
+ other applications during startup, extra care must be taken to
+ avoid incompatibility. Incompatible changes in the core
+ applications may in some situations be necessary. If possible,
+ such changes are preceded by deprecation over two major
+ releases before the actual change. To make sure your
+ application is not crashed by an incompatible change, always
+ remove any call to deprecated functions as soon as
+ possible.
+
An info report is written when the upgrade is completed. To
programatically find out if the upgrade is complete,
call release_handler:which_releases(current) and check
--
cgit v1.2.3