Erlang 21, Stability and the murder of an innocent Statemachine

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Erlang 21, Stability and the murder of an innocent Statemachine

José Valim-3

What about documentation from the OTP team that outlines a deprecation policy? It may be a good opportunity to also outline other compatibility guarantees, such as the compiled bytecode guarantees and the node compatibility guarantees, if such are not yet documented.

We did define such document not long ago for Elixir. In terms of deprecations, we have two terms: "soft-deprecation" and "hard-deprecation". The soft-deprecation is added as soon as a new implementation exists. At this point we don't emit any warnings, but we do update the docs to say the feature will warn in the future and start to point folks towards better ways.

A hard-deprecation is when we finally start emitting warnings. A hard-deprecation can only be added after an alternative exists for at least 2 Elixir releases. This is very important because it means that, once a feature is hard deprecated, you know you can use the proposed alternative and that alternative is supported at least two versions back.

This is only necessary if a feature is being replaced. In case a feature is being removed, such as non-smp VM versions, you may skip directly to the "hard-deprecation" and emit warnings straight-away since there won’t be an alternative in the future anyway.

I am not proposing for Erlang/OTP team to follow those rules and conventions but writing *some* rules as minimum guarantees may improve communication and help the community plan in terms of warnings, deprecations and removals accordingly. I would just avoid emitting deprecation warnings in the same version that an alternative is introduced, because it means library developers need to either only support the latest version or introduce conditionals (either at compile-time or runtime) to support multiple versions.

José Valim
Founder and 
Director of R&D

--


José Valim
Founder and 
Director of R&D

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang 21, Stability and the murder of an innocent Statemachine

Michael Truog
In reply to this post by Ingela Andin
On 05/06/2018 11:34 PM, Ingela Andin wrote:
Hi!

2018-05-04 14:40 GMT+02:00 Mahesh Paolini-Subramanya <[hidden email]>:
To echo Heinz's point, is there a *reason* for the deprecation?

Enquiring minds want to know...


Th point is to phase out gen_fsm. The deprecated warning is important to get new users to choose gen_statem. Also if you have a living product you will probably be better of in the long run changing to gen_statem. This
is not a complicated change and an exampel of how to do it is given in the gen_fsm manual page. Of course we give lots of time to adopt. We have no plan of removing the gen_fsm code swiftly, it is there in 20 and 21. 
I can see the deprecating process needs to enhanchend, and yes it sort of has more that one purpose which seems to conflict a bit.

One thing that might help is if we have the ability to deprecate types which I entered an entry for at https://bugs.erlang.org/browse/ERL-335 .  For example,  when all the time units switched from a format like milli_seconds to millisecond in Erlang/OTP 20.0 it would have been easier to have a deprecated type that can be used for an easier to understand warning.  That may seem like a small issue that can be avoided by switching to other functions or modules, but often changes don't need to be large for small changes that can be limited to type changes.

Best Regards,
Michael

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang 21, Stability and the murder of an innocent Statemachine

Mike French
In reply to this post by José Valim-3

So you have

-          ‘soft-deprecation’  with doc notes, but no compiler warnings

-          ‘hard-deprecation’ with compiler warnings, but no feature removal

 

I suggest the third stage would be:

-          ‘end-of-life’ with compiler warnings, and there is a
known future release when the original feature will vanish

 

Mike

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of José Valim
Sent: Monday, May 07, 2018 9:55 AM
To: Lloyd R. Prentice <[hidden email]>
Cc: [hidden email] Questions <[hidden email]>
Subject: Re: [erlang-questions] Erlang 21, Stability and the murder of an innocent Statemachine

 

 

What about documentation from the OTP team that outlines a deprecation policy? It may be a good opportunity to also outline other compatibility guarantees, such as the compiled bytecode guarantees and the node compatibility guarantees, if such are not yet documented.

 

We did define such document not long ago for Elixir. In terms of deprecations, we have two terms: "soft-deprecation" and "hard-deprecation". The soft-deprecation is added as soon as a new implementation exists. At this point we don't emit any warnings, but we do update the docs to say the feature will warn in the future and start to point folks towards better ways.

 

A hard-deprecation is when we finally start emitting warnings. A hard-deprecation can only be added after an alternative exists for at least 2 Elixir releases. This is very important because it means that, once a feature is hard deprecated, you know you can use the proposed alternative and that alternative is supported at least two versions back.

 

This is only necessary if a feature is being replaced. In case a feature is being removed, such as non-smp VM versions, you may skip directly to the "hard-deprecation" and emit warnings straight-away since there won’t be an alternative in the future anyway.

 

I am not proposing for Erlang/OTP team to follow those rules and conventions but writing *some* rules as minimum guarantees may improve communication and help the community plan in terms of warnings, deprecations and removals accordingly. I would just avoid emitting deprecation warnings in the same version that an alternative is introduced, because it means library developers need to either only support the latest version or introduce conditionals (either at compile-time or runtime) to support multiple versions.

 

José Valim

Founder and 

Director of R&D

 

--

 

 

José Valim

Founder and 

Director of R&D


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang 21, Stability and the murder of an innocent Statemachine

Kenneth Lundin-5
In reply to this post by Heinz N. Gies


On Mon, May 7, 2018 at 8:54 AM, José Valim <[hidden email]> wrote:

What about documentation from the OTP team that outlines a deprecation policy? It may be a good opportunity to also outline other compatibility guarantees, such as the compiled bytecode guarantees and the node compatibility guarantees, if such are not yet documented.

I think it is a good idea to describe the OTP policy regarding deprecation, backward compatibility, supported releases etc. in one place. Will try to have it available before the OTP 21 release.

The Elixir policy with hard and soft deperecation is also interesting as we need to make it
clearer what a depercation means.


But in short we use the deprecation mechanism to flag that a function och application is no longer recommended for use in new code since there exist another solution that we recomment to be used instead.

We don't remove deprecated functions or applications just like that and some functions have to stay for a very long time (or forever) since there is so much usage of them.

gen_fsm is an old module which is used a lot and it is not likely to dissapear in a near future. I realize that the deprecated attribute inside the module like this
-deprecated({start, 3, next_major_release}).
is somewhat misleading and we will try to improve this.

/Kenneth, Erlang/OTP
 

We did define such document not long ago for Elixir. In terms of deprecations, we have two terms: "soft-deprecation" and "hard-deprecation". The soft-deprecation is added as soon as a new implementation exists. At this point we don't emit any warnings, but we do update the docs to say the feature will warn in the future and start to point folks towards better ways.

A hard-deprecation is when we finally start emitting warnings. A hard-deprecation can only be added after an alternative exists for at least 2 Elixir releases. This is very important because it means that, once a feature is hard deprecated, you know you can use the proposed alternative and that alternative is supported at least two versions back.

This is only necessary if a feature is being replaced. In case a feature is being removed, such as non-smp VM versions, you may skip directly to the "hard-deprecation" and emit warnings straight-away since there won’t be an alternative in the future anyway.

I am not proposing for Erlang/OTP team to follow those rules and conventions but writing *some* rules as minimum guarantees may improve communication and help the community plan in terms of warnings, deprecations and removals accordingly. I would just avoid emitting deprecation warnings in the same version that an alternative is introduced, because it means library developers need to either only support the latest version or introduce conditionals (either at compile-time or runtime) to support multiple versions.

José Valim
Founder and 
Director of R&D

--


José Valim
Founder and 
Director of R&D

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang 21, Stability and the murder of an innocent Statemachine

Rickard Green-2


On Mon, May 7, 2018 at 12:06 PM, Kenneth Lundin <[hidden email]> wrote:


On Mon, May 7, 2018 at 8:54 AM, José Valim <[hidden email]> wrote:

What about documentation from the OTP team that outlines a deprecation policy? It may be a good opportunity to also outline other compatibility guarantees, such as the compiled bytecode guarantees and the node compatibility guarantees, if such are not yet documented.

I think it is a good idea to describe the OTP policy regarding deprecation, backward compatibility, supported releases etc. in one place. Will try to have it available before the OTP 21 release.


Document available in PR-1839 <https://github.com/erlang/otp/pull/1839>

Regards,
Rickard
--
Rickard Green, Erlang/OTP, Ericsson AB

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12