Mojolicious Google Group

about deprecation policy

2013-05-22T13:00:52Z

Hi all,

FYR

Perl5 deprecation
policy<[link]>

exception.json.ep use where default_format is not JSON.

2013-05-21T16:55:58Z

I'm building a Mojo app that serves both HTML and JSON. I make extensive
use of 'respond_to' to tailor the results back in either JSON or HTML
depending on the accept headers.
respond_to is working as expected, but I've noticed render_exception always
serves the HTML template even when exception.json.ep is defined, and the

Re: Mojo::DOM encoding bug?

2013-05-21T09:01:18Z

Hi,
I don't seem to find the proper alternative for
$at_dom->charset('windows-1255 ') when parsing a dom element.
Can you help me out?

Re: [Mojolicious] Mojolicious deprecation policy problems

2013-05-20T12:34:40Z

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

Re: Mojolicious deprecation policy problems

2013-05-20T02:17:26Z

I have banned Bernhard and myself from this list.

--
sebastian

Re: [Mojolicious] Re: Mojolicious deprecation policy problems

2013-05-20T00:44:42Z

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.

--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.com

Re: [Mojolicious] Re: Mojolicious deprecation policy problems

2013-05-19T22:47:23Z

Am 20.05.2013 00:13, schrieb sri:

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?

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

Bernhard

Re: Mojolicious deprecation policy problems

2013-05-19T22:13:33Z

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

[link]

I would very much appreciate it if only those that really care about

Re: [Mojolicious] Re: Mojolicious deprecation policy problems

2013-05-19T21:52:57Z

Am 19.05.2013 21:47, schrieb Joel Berger:

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

Re: [Mojolicious] Re: Mojolicious deprecation policy problems

2013-05-19T20:05:40Z

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

Re: [Mojolicious] Re: Mojolicious deprecation policy problems

2013-05-19T19:47:47Z

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

Re: [Mojolicious] Mojolicious deprecation policy problems

2013-05-19T19:45:14Z

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

Re: [Mojolicious] Re: Mojolicious deprecation policy problems

2013-05-19T19:35:30Z

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

Re: [Mojolicious] Re: Mojolicious deprecation policy problems

2013-05-19T18:53:23Z

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,

Re: Mojolicious deprecation policy problems

2013-05-19T18:26:43Z

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

--
sebastian