Mojolicious deprecation policy problems

[Виктор Турский]

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

[Bernhard Graf]

/me fully agrees

Of course I appreciate the pace in the Mojo development, but please,
dear mojolicious core team, consider, that there may be quite a few Mojo
based applications out there in production use.

Suddenly broken plugins on CPAN is probably only the top of the iceberg.


Bernhard

[Sebastian Riedel]

> 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.


No, this is not going to happen. Not all features can be deprecated, not every change is a clean removal. Once a year we need to be able to make real breaking changes to keep the code clean and Mojolicious relevant.

--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[Bernhard Graf]

Am 17.05.2013 21:37, schrieb Sebastian Riedel:

> No, this is not going to happen. Not all features can be deprecated, not every change is a clean removal. Once a year we need to be able to make real breaking changes to keep the code clean and Mojolicious relevant.

What is the problem with announcing such breaking changes before a release?


Bernhard

[Glen]

What purpose would it serve? Blindly upgrading dependencies will get you in trouble everywhere in life.

If a new release breaks an existing app, don't upgrade. Whether knowledge of the breakage is known before or after a release seems irrelevant.

Backpan is an excellent resource:
http://backpan.perl.org/authors/id/S/SR/SRI/


On May 17, 2013, at 1:38 PM, Bernhard Graf <***@gmail.com> wrote:

> Am 17.05.2013 21:37, schrieb Sebastian Riedel:
>
>> No, this is not going to happen. Not all features can be deprecated, not every change is a clean removal. Once a year we need to be able to make real breaking changes to keep the code clean and Mojolicious relevant.
>
> What is the problem with announcing such breaking changes before a release?
>
>
> Bernhard
>
> --
> You received this message because you are subscribed to the Google Groups "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
> To post to this group, send email to ***@googlegroups.com.
> Visit this group at http://groups.google.com/group/mojolicious?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Sebastian Riedel]

> Backpan is an excellent resource:
> http://backpan.perl.org/authors/id/S/SR/SRI/

Also tools such as Carton.

https://metacpan.org/module/Carton

--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[Виктор Турский]

2013/5/17 Sebastian Riedel <***@googlemail.com>:
> Also tools such as Carton.
Yep, I use Carton with all my applications and it really helps to run
ONLY existing code. It sounds like "do not use the latest version of
the Mojolicious because it has incompatibility bug". Mojolicious is
awesome and one of its best sides - is extensions support(plugins).
Plugins make Mojolicous ecosystem which is very important for the
framework future. Therefore it is important to have plugins working on
the CPAN.
So. the main idea of deprecation policychanges is to increase
Mojolicious infrastructural stability.

When you start the new app you will install the latest versions form
the CPAN and they will be broken.

--
Viktor Turskyi
http://webbylab.com
http://koorchik.blogspot.com

[Bernhard Graf]

Am 17.05.2013 21:48, schrieb Glen:

> What purpose would it serve? Blindly upgrading dependencies will get
> you in trouble everywhere in life.
>
> If a new release breaks an existing app, don't upgrade. Whether
> knowledge of the breakage is known before or after a release seems
> irrelevant.
>
> Backpan is an excellent resource:
> http://backpan.perl.org/authors/id/S/SR/SRI/

This is grist to the mill of the Never-touch-a-running-system
department. Won the battle, lost the war.

N8.

[Виктор Турский]

2013/5/17 Glen <***@empireenterprises.com>:
> What purpose would it serve? Blindly upgrading dependencies will get you in
> trouble everywhere in life.
It makes possible to prepare CPAN plugins for coming changes. If I
know that render_text($text) will be removed then I will rewrite the
plugin with the render(text=>$text) and it will be compatible with the
future releases. Currently it is IMPOSSIBLE to predict this and my
plugins(not only mine) are broken. The main problem that it is not
possible to avoid this if the framework incompatible changes were not
announced in advance.

--
Viktor Turskyi
http://webbylab.com
http://koorchik.blogspot.com

[s***@bykov.odessa.ua]

+ 1

> 2013/5/17 Glen <***@empireenterprises.com>:
>> What purpose would it serve? Blindly upgrading dependencies will get you in
>> trouble everywhere in life.
> It makes possible to prepare CPAN plugins for coming changes. If I
> know that render_text($text) will be removed then I will rewrite the
> plugin with the render(text=>$text) and it will be compatible with the
> future releases. Currently it is IMPOSSIBLE to predict this and my
> plugins(not only mine) are broken. The main problem that it is not
> possible to avoid this if the framework incompatible changes were not
> announced in advance.
>
> --
> Viktor Turskyi
> http://webbylab.com
> http://koorchik.blogspot.com
>

[sri]

> It makes possible to prepare CPAN plugins for coming changes. If I
> know that render_text($text) will be removed then I will rewrite the
> plugin with the render(text=>$text) and it will be compatible with the
> future releases.

You're completely ignoring the other half of the patch that removed
render_* methods, it also added render_maybe and changed completely
how rendering works internally. Maybe *you* don't care about those
specifics because you were lucky and it didn't affect your code, but
there is no truly "clean" deprecation path for changes like that.

> Currently it is IMPOSSIBLE to predict this and my
> plugins(not only mine) are broken. The main problem that it is not
> possible to avoid this if the framework incompatible changes were not
> announced in advance.

I assume you're using the words "announce" and "deprecate"
interchangeably and will just play along. In your original post you
highlighted that Mojolicious is released often, guess what, that's
impossible if we have to announce every change 3 months in advance. We
basically would have to switch to a Rails model of yearly releases and
freeze development for 3 months before the next release.

--
sebastian

[Ben van Staveren]

Here's my 2 cents; yes, this latest release broke some of my code. But as with
anything, a quick look at Changes will often point you in the right direction,
and 5 minutes of work fixed it all.

On that note I want to say this: If you upgrade Mojolicious in your production
environment, you run the risk of your code breaking in new and interesting
ways due to deprecated methods or other changes. That's why it's generally
considered a bad idea to upgrade anything on production that hasn't gone
through a round of testing first. That's the whole reason I caught the
breakage, fixed it, deployed my new version, upgraded Mojolicious, and was
humming along nicely the mentioned 5 minutes later.

However...

In the case of the render_* methods, what would have been nice (and this is
just my opinion) is to still have them, with deprecation warnings to the log,
and internally they just call self->render([text|json|data] => ...) so they
get the benefit of the new render handling code, and everyone else gets the
benefit of their code still working. And after a suitable amount of time has
passed (let's say a week or two, maybe a month) you remove them permanently,
and anyone caught bitching can be pointed at their log files (that everyone
does look at from time to time, right?) to see that they had plenty of early
warning.

I realise it may not have been feasible to do it like that, but doing it in
that fashion should cut down on the amount of "ehrmehgehrd my code broke
because of ...." stuff.

So maybe it was 3 cents...

On 05/19/2013 09:42 PM, sri wrote:
>> It makes possible to prepare CPAN plugins for coming changes. If I
>> know that render_text($text) will be removed then I will rewrite the
>> plugin with the render(text=>$text) and it will be compatible with the
>> future releases.
> You're completely ignoring the other half of the patch that removed
> render_* methods, it also added render_maybe and changed completely
> how rendering works internally. Maybe *you* don't care about those
> specifics because you were lucky and it didn't affect your code, but
> there is no truly "clean" deprecation path for changes like that.
>
>> Currently it is IMPOSSIBLE to predict this and my
>> plugins(not only mine) are broken. The main problem that it is not
>> possible to avoid this if the framework incompatible changes were not
>> announced in advance.
> I assume you're using the words "announce" and "deprecate"
> interchangeably and will just play along. In your original post you
> highlighted that Mojolicious is released often, guess what, that's
> impossible if we have to announce every change 3 months in advance. We
> basically would have to switch to a Rails model of yearly releases and
> freeze development for 3 months before the next release.
>
> --
> sebastian
>

--
Ben van Staveren
phone: [phone]
email: ***@gmail.com

[Sebastian Riedel]

> In the case of the render_* methods, what would have been nice (and this is just my opinion) is to still have them, with deprecation warnings to the log, and internally they just call self->render([text|json|data] => ...) so they get the benefit of the new render handling code, and everyone else gets the benefit of their code still working.


Or not, now the ones that get hit by the new render internals start asking for stricter deprecation policies.

--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Cosimo Streppone]

On 05/19/2013 04:42 PM, sri wrote:

> You're completely ignoring the other half of the patch that removed
> render_* methods, it also added render_maybe and changed completely
> how rendering works internally. Maybe *you* don't care about those
> specifics because you were lucky and it didn't affect your code, but
> there is no truly "clean" deprecation path for changes like that.

Most users don't care about internals.
Why not improve your changelog document instead?

https://metacpan.org/module/TIMB/DBI-1.627/Changes

Breaking changes, deprecation and compatibility notices are
always on top, and clearly indicated as such.

IMO they should also inform about alternatives,
rather than say "Removed foo()".

Example:

BREAKING CHANGE: render_json() and render_text() are *removed*.
From now on, use render({text|json} => ...) instead.

The order is also more meaningful, with such changes and
deprecations always on top, followed by fixes. Much more
likely that people will notice them if they skim through
the content.

Since we're talking changelog, I find the repeated
"Improved documentation" and "Improved tests" a bit silly.
They add no useful information.

--
Cosimo

[Виктор Турский]

2013/5/19 sri <***@googlemail.com>:
> I assume you're using the words "announce" and "deprecate"
> interchangeably and will just play along.
The main idea that developers should know that stable features will be
changed/removed. It can be done with deprecation warnings or
deprecation annoucement.

>In your original post you highlighted that Mojolicious is released often, guess what, that's
>impossible if we have to announce every change 3 months in advance.
I mean that Mojolicious is released more often than once per three
months. This is good because a release with deprecated features(and
deprecated warnings) will be available earlier and there will be
enough time to rewrite code. I like often releases. And deprecation
policy works good with them(except cases with major releases).

--
Viktor Turskyi
http://webbylab.com
http://koorchik.blogspot.com

[sri]

> I mean that Mojolicious is released more often than once per three
> months. This is good because a release with deprecated features(and
> deprecated warnings) will be available earlier and there will be
> enough time to rewrite code. I like often releases. And deprecation
> policy works good with them(except cases with major releases).

You didn't think this through, like i said before, many changes can't
be made without breaking something. Therefore we would have to hold
back all "announced" breaking changes for at least 3 months and freeze
development in the meantime, or we end up with a huge mess of branches
that can only be merged into master after 3 months, slowing down all
development. And that's why i concluded that we have to switch to a
yearly release schedule to make it actually work.

--
sebastian

[sri]

> Therefore we would have to hold
> back all "announced" breaking changes for at least 3 months and freeze
> development in the meantime, or we end up with a huge mess of branches
> that can only be merged into master after 3 months, slowing down all
> development.

But it doesn't end here, lets finish this thought. Even if we could
make it work somehow, it would ultimately make the problem worse,
because now we can have breaking changes all around the year!!!1

Let me give you an example:
May 25: 4.01 release announcing the addition of a new reserved stash
value in 3 months, which is a breaking change.
June 3: 4.05 release announcing that all render methods will now
return the invocant instead of true/false, another breaking change.
June 11: 4.09 release announcing that respond_to content negotiation
will now honor other previously ignored headers, yet another breaking
change.
...
August 25: 4.21 release with a breaking change.
September 3: 4.32 release with another breaking change.
September 11: 4.33 release with yet another breaking change.
...

We go from breaking changes once a year to breaking changes every
week.

--
sebastian

[sri]

> ...now we can have breaking changes all around the year!!!1

And when i say "breaking changes" i specifically mean those that can't
be phased out slowly with a deprecation warning in code.

> June 3: 4.05 release announcing that all render methods will now
> return the invocant instead of true/false, another breaking change.
> June 11: 4.09 release announcing that respond_to content negotiation
> will now honor other previously ignored headers, yet another breaking
> change.

That sounds awkward, pretend i said "in 3 months" for both.

--
sebastian

[sri]

Lets move the discussion into a different direction, which Perl
project do you think has a better deprecation policy/release cycle and
why?

--
sebastian

[Marty Tennison]

I'd like to throw in my opinion. Personally, I have no problem with the
current deprecation policy. My opinion is, and always will be "Let the
current developers decide on the best policy that works for them". There
is no perfect solution that will fit everyone but one thing for sure, a
stagnate project due to developer disinterest or frustration serves nobody,
and there are plenty of examples of that phenomenon.


On Sun, May 19, 2013 at 11:26 AM, sri <***@googlemail.com> wrote:

> Lets move the discussion into a different direction, which Perl
> project do you think has a better deprecation policy/release cycle and
> why?
>
> --
> sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+***@googlegroups.com.
> To post to this group, send email to ***@googlegroups.com.
> Visit this group at http://groups.google.com/group/mojolicious?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


--

- - -- ---- ---------------------------------------------------- --- -- - -
Marty Tennison Drip Depot Inc
email: ***@dripdepot.com
web: www.dripdepot.com
phone: [phone]
fax: [phone]
- -- --- ---------------------------------------------------------- --- --

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Stefan Adams]

For me, ultimately I agree with sri; but I am concerned about plugins. It
does rather stink that should someone get into Mojolicious on, say, the day
4.0 was released and then attempts to use plugin X they would
understandably be frustrated when this plugin does not work. It's extremely
unreasonable to expect the plugin author to update the plugin instantly
upon framework update. But what policy could really resolve this? What if
the plugin author doesn't keep up with the times and a month or three goes
by and the plugin is still not updated?

I've understood two distinct perspectives in this discussion: app
developers and plugin developers. App developers need to simply not update
blindly. Plugin developers? I don't know... How can plugins be helped
through the update cycle? Regardless of the update cycle, however, plugins
are at risk of breakage. But can they at least be assisted some how?

On May 19, 2013 8:53 AM, "Marty Tennison" <***@dripdepot.com>
wrote:
>
> I'd like to throw in my opinion. Personally, I have no problem with the
current deprecation policy. My opinion is, and always will be "Let the
current developers decide on the best policy that works for them". There
is no perfect solution that will fit everyone but one thing for sure, a
stagnate project due to developer disinterest or frustration serves nobody,
and there are plenty of examples of that phenomenon.

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Joel Berger]

I've just been saying essentially the same thing on IRC. I like the fast
pace for Mojolicious development, but its too bad that on a breaking
release plugins will break. In truth nothing can be done about that. Even
if a module author is ready for the major Mojo release, they have to wait
until after Mojo goes out, so there MUST be a time in which their plugin is
broken.

I think that the best case is that the module authors be alerted with
enough time to make changes. What is being discussed on IRC is a 1 week
"freeze" prior to a major release. I suggest that that be concurrent with a
posting to the world, perhaps on a blog or something more broadly visible
than a list post or IRC message, saying,

"We expect to release Mojolicious X.0 on day Y. There will be some breaking
changes which module authors ought to consider and prepare for updating
their plugins, we hope that no further breaking changes will be made from
the current state of the repository. We reserve the right to push this date
back if needed to accomodate late-breaking developments however."

Does this sound useful? I would hate to slow the pace any more than about a
week. When a breaking change is needed, sometimes its because it it
necessary not just desirable. In these cases the Core Developement Team
needs to be able to respond quickly.

Thoughts?

On Sunday, May 19, 2013 2:35:30 PM UTC-5, Stefan wrote:
>
> For me, ultimately I agree with sri; but I am concerned about plugins. It
> does rather stink that should someone get into Mojolicious on, say, the day
> 4.0 was released and then attempts to use plugin X they would
> understandably be frustrated when this plugin does not work. It's extremely
> unreasonable to expect the plugin author to update the plugin instantly
> upon framework update. But what policy could really resolve this? What if
> the plugin author doesn't keep up with the times and a month or three goes
> by and the plugin is still not updated?
>
> I've understood two distinct perspectives in this discussion: app
> developers and plugin developers. App developers need to simply not update
> blindly. Plugin developers? I don't know... How can plugins be helped
> through the update cycle? Regardless of the update cycle, however, plugins
> are at risk of breakage. But can they at least be assisted some how?
>
> On May 19, 2013 8:53 AM, "Marty Tennison" <***@dripdepot.com<javascript:>>
> wrote:
> >
> > I'd like to throw in my opinion. Personally, I have no problem with
> the current deprecation policy. My opinion is, and always will be "Let the
> current developers decide on the best policy that works for them". There
> is no perfect solution that will fit everyone but one thing for sure, a
> stagnate project due to developer disinterest or frustration serves nobody,
> and there are plenty of examples of that phenomenon.
>

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Bernhard Graf]

Am 19.05.2013 21:47, schrieb Joel Berger:

> I've just been saying essentially the same thing on IRC. I like the fast
> pace for Mojolicious development, but its too bad that on a breaking
> release plugins will break. In truth nothing can be done about that.
> Even if a module author is ready for the major Mojo release, they have
> to wait until after Mojo goes out, so there MUST be a time in which
> their plugin is broken.

That is simply not true.

One of my own plugins (M:P:AccessLog) broke, because method is_dynamic
has been removed from Mojo::Message. If anybody would have announced
that breaking change for M4, I easily could have fixed that just before
the M4 release by replacing $response->is_dynamic with
$response->content->is_dynamic, which runs fine on M4 /and/ earlier
versions (... something, that is not possible, if I got you right).


Bernhard

[sri]

> That is simply not true.

You sir have been disqualified from this discussion for depending on
Mojolicious internals in your plugins.

https://metacpan.org/source/GRAF/Mojolicious-Plugin-MethodOverride-0.010/lib/Mojolicious/Plugin/MethodOverride.pm#L18

I would very much appreciate it if only those that really care about
the issue participate, thank you.

--
sebastian

[Bernhard Graf]

Am 20.05.2013 00:13, schrieb sri:

> You sir have been disqualified from this discussion for depending on
> Mojolicious internals in your plugins.
>
> https://metacpan.org/source/GRAF/Mojolicious-Plugin-MethodOverride-0.010/lib/Mojolicious/Plugin/MethodOverride.pm#L18

Feel free to send me a patch.

Since you seem to know every mediocre Mojolicous plugin inside out, does
that mean, you broke them on purpose?

> I would very much appreciate it if only those that really care about
> the issue participate, thank you.

My impression was, that esp. you care least about that issue.


Bernhard

[Ben van Staveren]

I'm not usually one to say this but can both of you either take this to
private mail or shut up? Going at it like a bunch of kids in kindergarten
isn't going to do any good.

On 05/20/2013 05:47 AM, Bernhard Graf wrote:
> Am 20.05.2013 00:13, schrieb sri:
>
>> You sir have been disqualified from this discussion for depending on
>> Mojolicious internals in your plugins.
>>
>> https://metacpan.org/source/GRAF/Mojolicious-Plugin-MethodOverride-0.010/lib/Mojolicious/Plugin/MethodOverride.pm#L18
>
> Feel free to send me a patch.
>
> Since you seem to know every mediocre Mojolicous plugin inside out, does
> that mean, you broke them on purpose?
>
>> I would very much appreciate it if only those that really care about
>> the issue participate, thank you.
>
> My impression was, that esp. you care least about that issue.
>
>
> Bernhard
>

--
Ben van Staveren
phone: [phone]
email: ***@gmail.com

[sri]

> I'm not usually one to say this but can both of you either take this to
> private mail or shut up?

I have banned Bernhard and myself from this list.

--
sebastian

[Charlie Brady]

On Sun, 19 May 2013, Joel Berger wrote:

> I've just been saying essentially the same thing on IRC. I like the fast
> pace for Mojolicious development, but its too bad that on a breaking
> release plugins will break. In truth nothing can be done about that. Even
> if a module author is ready for the major Mojo release, they have to wait
> until after Mojo goes out, so there MUST be a time in which their plugin is
> broken.

Are you sure? Plugins can behave differently for different versions of
Mojo. They can use eval/can etc to test for breakage, and DTRT. So
forewarnded can mean forearmed.

I would think that plugin authors would actually want, when possible, to
support both bleeding edge and older versions of Mojolicious. So they
would be doing this special treatment for feature changes anyway.

---
Charlie

[Sebastian Riedel]

> It's extremely unreasonable to expect the plugin author to update the plugin instantly upon framework update. But what policy could really resolve this? What if the plugin author doesn't keep up with the times and a month or three goes by and the plugin is still not updated?

The problem goes even deeper than that, there will always be a period in which plugins are broken. Even if we give an advance warning and plugin authors update their modules before we release Mojolicious, those plugins would be broken with older versions of Mojolicious. That's what i mean when i talk about "clean deprecation path".

--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Виктор Турский]

Ok. Minor releases are often and deprecation policy already works
with minor releases because changes are not so fundamental. With major
releases it is much harder to keep backwards compatibility. I agree
with that. So my suggestions are
1. For minor releases leave deprecation policy as is.

2. For major releases use deprecation period(with deprecation
warnings) where it possible and not very hard.
Often renaming/removing methods can have deprecation period.
It is not so critical to remove "sub render_text { shift->render(text
=> @_) }" without deprecation. This will add some stability.

3. Major releases are rare and it is possible to use short(2-3 weeks)
stabilization period(no upload to CPAN). A major release could be
announced everywhere with a note "Please, retest your code(especially
plugins on the CPAN) with the new major release - X.0. After two weeks
it will be released to CPAN"(or something like that). A developer
takes the latest version from Github and has a chance to fix
incompatilities. Optionally pre-release version could be uploaded to
the CPAN as a "DEVELOPMENT
RELEASE"(http://search.cpan.org/~andya/Perl-Version-1.011/lib/Perl/Version.pm#Alpha_Versions).

I want to give a chance for plugin developers to keep their plugins
always in working state.

Maybe my suggestions are not the best ones and there are much better
solutions or maybe the current release schema is the most effective
one. In any case we have a lot of time till the next major release :)



--
Viktor Turskyi
http://webbylab.com
http://koorchik.blogspot.com

[Stanislav Blinov]

I have updated Mojo to 4.0 and my applications is broken - some routes
are not working anymore, in many places I have used $self->render_json
or $self->render_text that I now need to change.
This is a really strange policy.
I feel a strong disappointment with Mojo. Maybe for my next projects I
should consider another framework...

[Wes Cravens]

In my opinion this doesn't really have that much to do with Mojolicious
deprecation policy or release schedule.

Application breakage going from 3.nn to 4.0 is completely
understandable. I'd challenge anyone to migrate an application from say
ExtJS 3.n to 4.n, or QT etc. I've been involved in several projects
where entire teams were built to handle the migration of an application
through a major library version change.

But I do think that there exists a very real problem with regard to
plugin maintenance expectations. I wish our plugin community in general
was better documented, supported, promoted and maintained. I wish that
we maintained a list of 'sanctioned' plugins, known to be examples of
best practice and actively maintained. Perhaps this already exists and
I've overlooked it; but to me our plugin community lacks a certain
credibility (perhaps just a marketing problem).

Anyway, to me this seems to be the real symptom and the deprecation
policy of Mojolicious isn't the right direction for the cure.

Wes

[Sam Wong]

Thank you for all the hard work from all the contributors.
Mojolicious is a very nice piece that completes the perl web app
development puzzle, but it could be even better if deprecation could be
handled better.

I am an application developer and have been staying with Mojolicious since
0.98 (or is it - I don't recall the exact ver number).
Over the time, two breaking changes affected me - 1) introduction of
Mojolicios::Command->start_app, 2) removal of render_json.

To an app dev, there are two problems with the breaking changes -
a) I don't know (not even a ballpark idea) what will be broken if I upgrade
b) I don't know how to fix the app

May I take this chance to voice out how I think it could be done better.
* Communication channel - POD please.
I don't usually subscribe mailing list or IRC of a module, because it won't
be possible for me to following hundreds of mailing list of modules that I
am using, and very often I don't find the need to. Say - I don't think it's
expected for app dev to subscribe the mailing list of DBI, or Moose. Most
perl module usually keeps their interface stable.
I am suggesting please maintain a "delta" POD like Perl, and announce all
the breaking changes over there, and how to app/module dev could adopt the
changes. I recall it took me an hour to adopt my index.pl to the new
start_app syntax because I wasn't able to find the new syntax all over the
other documents, even if it's a link to the wiki. When app dev are
introduced with a perl module, pod should be the only thing that we are
supposed to read, not wiki, not mailing list, not IRC - it is highly
visible on CPAN, it is stable and properly archived on CPAN.

* Deprecation
This is a framework after all, consumed by thousands, or millions of module
and application code. Perl/CPAN make it not so easy to cherry-pick a
particular version of module to install, and even more difficult to install
a few version of module side by side or install it locally, and app dev to
pack the module and deploy locally (PAR has its limitations).
People won't be so happy if DBI breaks its API every other quarter.
It would be nice if breaking API changes (something like method removal
for cleaningness which is easy to do) could actually be kept in place for 1
major version, mark with warning message when invoked, with the changes
communicated on delta POD, and then actually remove only in the next major
version. That makes fewer surprises and oops for sure.

Thanks,
Sam

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Glen]

- Breaking changes can be found by running your app's test suite using the new release.

- Previous releases can easily be accessed via http://backpan.perl.org/authors/id/S/SR/SRI and installed directly in moments with cpanm:

cpanm http://backpan.perl.org/authors/id/S/SR/SRI/Mojolicious-3.97.tar.gz

- Deltas can be accessed using the github diff tool.

- You may want to look into something like http://search.cpan.org/~miyagawa/carton-v0.9_9/docs/carton.pod for managing apps.



On May 22, 2013, at 8:52 PM, Sam Wong <***@gmail.com> wrote:

> Thank you for all the hard work from all the contributors.
> Mojolicious is a very nice piece that completes the perl web app development puzzle, but it could be even better if deprecation could be handled better.
>
> I am an application developer and have been staying with Mojolicious since 0.98 (or is it - I don't recall the exact ver number).
> Over the time, two breaking changes affected me - 1) introduction of Mojolicios::Command->start_app, 2) removal of render_json.
>
> To an app dev, there are two problems with the breaking changes -
> a) I don't know (not even a ballpark idea) what will be broken if I upgrade
> b) I don't know how to fix the app
>
> May I take this chance to voice out how I think it could be done better.
> * Communication channel - POD please.
> I don't usually subscribe mailing list or IRC of a module, because it won't be possible for me to following hundreds of mailing list of modules that I am using, and very often I don't find the need to. Say - I don't think it's expected for app dev to subscribe the mailing list of DBI, or Moose. Most perl module usually keeps their interface stable.
> I am suggesting please maintain a "delta" POD like Perl, and announce all the breaking changes over there, and how to app/module dev could adopt the changes. I recall it took me an hour to adopt my index.pl to the new start_app syntax because I wasn't able to find the new syntax all over the other documents, even if it's a link to the wiki. When app dev are introduced with a perl module, pod should be the only thing that we are supposed to read, not wiki, not mailing list, not IRC - it is highly visible on CPAN, it is stable and properly archived on CPAN.
>
> * Deprecation
> This is a framework after all, consumed by thousands, or millions of module and application code. Perl/CPAN make it not so easy to cherry-pick a particular version of module to install, and even more difficult to install a few version of module side by side or install it locally, and app dev to pack the module and deploy locally (PAR has its limitations).
> People won't be so happy if DBI breaks its API every other quarter.
> It would be nice if breaking API changes (something like method removal for cleaningness which is easy to do) could actually be kept in place for 1 major version, mark with warning message when invoked, with the changes communicated on delta POD, and then actually remove only in the next major version. That makes fewer surprises and oops for sure.
>
> Thanks,
> Sam
>
> --
> You received this message because you are subscribed to the Google Groups "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
> To post to this group, send email to ***@googlegroups.com.
> Visit this group at http://groups.google.com/group/mojolicious?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Виктор Турский]

2013/5/23 Sam Wong <***@gmail.com>:
> I am suggesting please maintain a "delta" POD like Perl
As for changes list it can be found in "Changes" file -
https://metacpan.org/source/SRI/Mojolicious-4.03/Changes



--
Viktor Turskyi
http://webbylab.com
http://koorchik.blogspot.com

[Heiko Jansen]

Am Donnerstag, 23. Mai 2013 10:16:04 UTC+2 schrieb koorchik:

> 2013/5/23 Sam Wong <***@gmail.com <javascript:>>:
> > I am suggesting please maintain a "delta" POD like Perl
> As for changes list it can be found in "Changes" file -
> https://metacpan.org/source/SRI/Mojolicious-4.03/Changes
>

ThatŽs fine but sometimes doesnŽt help you much.
A major improvement would IMHO be, if
a) the rationale behind a breaking change and
b) especially the new solution that replaced the deprecated feature
could be documented somewhere.

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.