EEP 56 - question

[Maria Scott]

Hello,

it just occurred to me that, while the changes discussed in the EEP introduce no backwards incompatibilities, they are also fully forward compatible (if that is a term =^^=), and that there lies a catch.

Imagine an application that uses the significant children feature as described in the EEP, in order to automatically shut down certain parts of it's supervision tree. As the new supervisor and child spec flags are new keys in the respective maps, this application will happily compile and run even on OTP versions predating this EEP, ignoring the new keys. However, the automatic shutdowns will never happen because the required mechanism is not in place in older OTP versions, and the application will be "leaking" supervisor processes.

Any idea how we could tackle this, anyone?

A safe way could be to add a new significant-related option to an existing key, instead of introducing new ones, at least for one of them. This would break in option value checking when used in an OTP version where the supervisor is not expecting the new value. I don't see any real nice place to fit this in, though.

Another option might be to just document it and let implementors decide if and how they might defend against it, maybe with an -if(?OTP_RELEASE =< ...) directive. But who ever reads docs? ^^;;;

Kind regards,
Maria Scott