ERL-1038: Release upgrade supervisors with side effects

[OTP-Maintainer]

Original reporter: juhlig
Affected version: Not Specified
Component: Not Specified
Migrated from: https://bugs.erlang.org/browse/ERL-1038

---

Release-upgrading a supervisor is currently handled by calling its `init/1` function again with the original arguments. This means a supervisor has no way to know if its init function is called due to a normal (re-)start, or as part of an upgrade (a possible workaround is using the process dictionary, though). Therefore, as the documentation points out, the init functions should be free of side effects.

While this is a noble goal in itself, I believe in everyday practice supervisors' init function often do have side effects for one reason or another. Those are hard to upgrade, or not upgradable at all.

I have two proposals to make the upgrading of supervisors with side effects possible.

Like the other OTP behaviors, supervisors could have a `code_change` function, as an optional callback. If it is there, we call it, if not we call init. While this is in line with the other OTP behaviors, it has some drawbacks. What do we give this function? The current supervisor flags and child specs maybe? The original arguments? Both? There is also the possibility that the flags and child specs it returns differ from what would be returned from init, so inconsistency could sneak in.

A different approach which I think is more feasible is putting an optional `pre_init` callback before `init`. If it is there, it gets called with the arguments that would normally go to init directly. It can do all the side effects it wants, then return (possibly changed) args to be passed further on to init.  init could then be truly side-effect free (just return the flags and child specs, really) and be called for upgrades as it is now.