Виктор Турский
2013-05-17 10:35:00 UTC
Hello, everyone!
I would like to talk about the Mojolicious deprecation policy. I
understand that the framework API is evolving and requires changes
from time to time. I agree that this is reasonable for the framework
development. Therefore, we have a lot of features marked
"experimental" that can be removed without any warnings. I always
check if a feature is experimental and use it on my own risk.
For stable features we have deprecation policy. Firstly, a feature is
marked as deprecated and only after some time passed the feature will
be removed. Deprecation policy makes the framework API changes more
predictable and does not stop the framework evolution.
But there are situation when we are all in a great risk that our
application written in Mojolicious will fail. I am talking about mojor
releases. And it happened. After the Mojolicious 4.0 release a lot of
Mojolicious::Controller *stable* method were removed without any
warnings. As for me these methods could go through deprecation policy.
I am talking about "render_text" and "render_json"(may be other). I
will explain why:
1. These methods do not prevent other features to be added.
From http://mojolicio.us/perldoc/Mojolicious/Guides/Contributing:
"Refactoring and deprecations should be avoided if no important
feature depends on it." What important features depend on removing
"render_text" and "render_json" method? I do not mind, let's remove
them but with deprecation period.
2. Removing these method without warnings breaks a lot of plugins.
Today I have broken plugins an the CPAN(for example,
https://metacpan.org/module/Mojolicious::Plugin::CSRFProtect). And it
is *impossible* to avoid this with current deprecation policy.
The only solution I see is changing deprecation policy from "Features
may only be changed in a major release or after being deprecated for
at least 3 months." to "Features may only be changed after being
deprecated for at least 3 months."
Mojolicious is released often and it is possible to mark features as
deprecated in advance even for major releases.
--
Viktor Turskyi
https://metacpan.org/author/KOORCHIK
I would like to talk about the Mojolicious deprecation policy. I
understand that the framework API is evolving and requires changes
from time to time. I agree that this is reasonable for the framework
development. Therefore, we have a lot of features marked
"experimental" that can be removed without any warnings. I always
check if a feature is experimental and use it on my own risk.
For stable features we have deprecation policy. Firstly, a feature is
marked as deprecated and only after some time passed the feature will
be removed. Deprecation policy makes the framework API changes more
predictable and does not stop the framework evolution.
But there are situation when we are all in a great risk that our
application written in Mojolicious will fail. I am talking about mojor
releases. And it happened. After the Mojolicious 4.0 release a lot of
Mojolicious::Controller *stable* method were removed without any
warnings. As for me these methods could go through deprecation policy.
I am talking about "render_text" and "render_json"(may be other). I
will explain why:
1. These methods do not prevent other features to be added.
From http://mojolicio.us/perldoc/Mojolicious/Guides/Contributing:
"Refactoring and deprecations should be avoided if no important
feature depends on it." What important features depend on removing
"render_text" and "render_json" method? I do not mind, let's remove
them but with deprecation period.
2. Removing these method without warnings breaks a lot of plugins.
Today I have broken plugins an the CPAN(for example,
https://metacpan.org/module/Mojolicious::Plugin::CSRFProtect). And it
is *impossible* to avoid this with current deprecation policy.
The only solution I see is changing deprecation policy from "Features
may only be changed in a major release or after being deprecated for
at least 3 months." to "Features may only be changed after being
deprecated for at least 3 months."
Mojolicious is released often and it is possible to mark features as
deprecated in advance even for major releases.
--
Viktor Turskyi
https://metacpan.org/author/KOORCHIK