[erlang-questions] Erlang 21, Stability and the murder of an innocent Statemachine
Fri May 4 14:57:18 CEST 2018
On 05/04/2018 02:03 PM, Heinz N. Gies wrote:
> I have thought of that but I don’t think that’s a real option.
> Deprication warnings are important
Code removal is an important problem which can't be avoided when you
have to support OTP versions before/after. So is fundamental additions
to the language (like maps). But I don't think warnings are nearly as
important, particularly deprecation warnings.
Deprecation warnings signal that your code will stop working one day in
the future so they are useful, but they say nothing of your code TODAY
which is what matters most. The code still builds and works fine
regardless of the warning.
I would say it's important to know that the code will stop working at
some point in the future so you can plan migrating the code. But you
still have at least a year to figure it out, it's not OTP-21 that breaks
your code, it will be OTP-22 or a later release.
If I was in your situation I would adopt the following strategy:
* Disable the deprecation warnings in normal builds
* Setup a separate build task/CI job for compiling with deprecation
warnings (xref checks those too IIRC)
* Open a ticket to remember to fix those and/or change the supported OTP
versions within that timespan
Dropping older versions will work even for many libraries because most
users are on the last 2-3 releases anyway. There's of course exceptions.
In general I would also say that while it's usually a good idea to fix
new warnings, sometimes the fix is uglier than the warning. If you need
to depend on externally defined macros or rewrite huge chunks of the
code to fix a warning, you might want to just leave the warning around
or disable it for now.
Warnings are great to anticipate problems but they should by no means
prevent working code from working.
All that being said, I think the OTP team has been a little too
aggressive with changes lately. It would be better to deprecate two
releases before removal (introduce gen_statem in 20, deprecate gen_fsm
in 21 and remove gen_fsm in 23). That would make transitioning easier
because one could switch from gen_fsm to gen_statem during the OTP-22
era while still supporting the last 3 releases and therefore the
majority of users would be unaffected.
More information about the erlang-questions