From a4290bb363fb6f1c593886d4f10a5868d7c9d3b8 Mon Sep 17 00:00:00 2001
From: Siri Hansen <siri@erlang.org>
Date: Wed, 15 Oct 2014 18:31:13 +0200
Subject: [sasl] Remove undocumented upgrade instruction

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.
---
 system/doc/design_principles/appup_cookbook.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'system')

diff --git a/system/doc/design_principles/appup_cookbook.xml b/system/doc/design_principles/appup_cookbook.xml
index 70c34a5a06..d9f7372aab 100644
--- a/system/doc/design_principles/appup_cookbook.xml
+++ b/system/doc/design_principles/appup_cookbook.xml
@@ -4,7 +4,7 @@
 <chapter>
   <header>
     <copyright>
-      <year>2003</year><year>2013</year>
+      <year>2003</year><year>2014</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -132,7 +132,7 @@ code_change(_Vsn, Chs, _Extra) ->
       loaded.</p>
     <p>Thus, <c>ch3</c> must be loaded before <c>m1</c> is, in
       the upgrade case, and vice versa in the downgrade case. We say
-      that <c>m1</c><em>is dependent on</em><c>ch3</c>. In a release
+      that <c>m1</c> <em>is dependent on</em> <c>ch3</c>. In a release
       handling instruction, this is expressed by the element
       <c>DepMods</c>:</p>
     <code type="none">
-- 
cgit v1.2.3