[erlang-questions] Erlang 21, Stability and the murder of an innocent Statemachine

[Loïc Hoguin]

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

Are they?

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.

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu