[Catalyst] Backlog for proposed changes in next Catalyst release

Tomas Doran bobtfish at bobtfish.net
Sun Mar 10 19:58:42 GMT 2013


Turning it into a role and making it optionally be applied would be a nice to have (i.e. so people could turn it off if needed).

It working seamlessly with apps which already use the (old) plugin is a *must* have (but to be fair - maybe we can just filter U::P::U::Encoding out of the plugin list if there, and break hard if old C::P::Unicode is found?)

Does anyone have a strong opinion on this being added to their app by default?

Does anyone have an app which needs you to NOT load the unicode plugin? Speak now, or you're gonna have a bad time :)

I'm all for this, and I'm feeling that our strategy of doing obsessive backwards compatibility has hurt us in the past. If you're not doing unicode right, your app is _broken_, and you need to fix it - if that stops you upgrading, then so be it.

If anyone cares enough to say this should make it 6.0, that's also cool.

Catalyst 6.0 "mandatory being correct"… Job done!

Cheers
t0m


On 5 Mar 2013, at 15:42, Bill Moseley <moseley at hank.org> wrote:

> 
> 
> On Tue, Mar 5, 2013 at 7:09 AM, John Napiorkowski <jjn1056 at yahoo.com> wrote:
> Bill, I think there's general agreement that the plugin is stable enough and right enough that it should represent core behavior.  Although one of Catalyst's strengths has been to be un-opinionated and leave stuff to external distributions when possible, I think this does fall under the 'all good apps should work this way'.  I've tentatively pegged it for the March Catalyst release, since it seems pretty straightforward, at least for now.  If you think you can fit it in (or talk your boss/clients/whatever into paying for your time) please give a shout out.  It would be great to see more people get to know Catalyst internals a bit, otherwise I don't really see how we are going to be able to move the platform forward.
> 
> The month of May is more likely for me, unfortunately. 
> 
> I was thinking of turning the plugin into a Role and then consuming if the plugin was not already listed or if a config option to disable was not set.  That is, on by default but can be disabled.   Is that in line with what you were thinking?
> 
> Ha!  I was looking at the code just now and saw a comment that included this URL:
> 
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg02350.html
> 
> I guess I've thought about this before....
>  
> 
> 
> 
> I wonder what percent of Catalyst apps make use of that plugin.
> 
>  Not sure, but I think the play-perl ticket has a good way to not break most people's code
> 
> 
> -- 
> Bill Moseley
> moseley at hank.org
> 
> 
> 
> 
> 
> -- 
> Bill Moseley
> moseley at hank.org _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/




More information about the Catalyst mailing list