view release on metacpan or  search on metacpan

lib/Catalyst/Upgrading.pod  view on Meta::CPAN

to work correctly.  Here's the known list:

L<Catalyst::View::TT>, L<Catalyst::View::Mason>, L<Catalyst::View::HTML::Mason>,
L<Catalyst::View::Xslate>, L<Test::WWW::Mechanize::Catalyst>

You will need to update to modern versions in most cases, although quite a few
of these only needed minor test case and documentation changes so you will need
to review the changelog of each one that is relevant to you to determine your
true upgrade needs.

=head1 Upgrading to Catalyst 5.90060

Starting in the v5.90059_001 development release, the regexp dispatch type is
no longer automatically included as a dependency.  If you are still using this
dispatch type, you need to add L<Catalyst::DispatchType::Regex> into your build
system.

The standalone distribution of Regexp will be supported for the time being, but
should we find that supporting it prevents us from moving L<Catalyst> forward
in necessary ways, we reserve the right to drop that support.  It is highly
recommended that you use this last stage of deprecation to change your code.

=head1 Upgrading to Catalyst 5.90040

=head2 Catalyst::Plugin::Unicode::Encoding is now core

The previously stand alone Unicode support module L<Catalyst::Plugin::Unicode::Encoding>
has been brought into core as a default plugin.  Going forward, all you need is
to add a configuration setting for the encoding type.  For example:

    package Myapp::Web;

    use Catalyst;

    __PACKAGE__->config( encoding => 'UTF-8' );

Please note that this is different from the old stand alone plugin which applied
C<UTF-8> encoding by default (that is, if you did not set an explicit
C<encoding> configuration value, it assumed you wanted UTF-8).  In order to
preserve backwards compatibility you will need to explicitly turn it on via the
configuration setting.  THIS MIGHT CHANGE IN THE FUTURE, so please consider
starting to test your application with proper UTF-8 support and remove all those
crappy hacks you munged into the code because you didn't know the Plugin
existed :)

For people that are using the Plugin, you will note a startup warning suggesting
that you can remove it from the plugin list.  When you do so, please remember to
add the configuration setting, since you can no longer rely on the default being
UTF-8.  We'll add it for you if you continue to use the stand alone plugin and
we detect this, but this backwards compatibility shim will likely be removed in
a few releases (trying to clean up the codebase after all).

If you have trouble with any of this, please bring it to the attention of the
Catalyst maintainer group.

=head2 basic async and event loop support

This version of L<Catalyst> offers some support for using L<AnyEvent> and
L<IO::Async> event loops in your application.  These changes should work
fine for most applications however if you are already trying to perform
some streaming, minor changes in this area of the code might affect your
functionality.  Please see L<Catalyst::Response\write_fh> for more and for a
basic example.

We consider this feature experimental.  We will try not to break it, but we
reserve the right to make necessary changes to fix major issues that people
run into when the use this functionality in the wild.

=head1 Upgrading to Catalyst 5.90030

=head2 Regex dispatch type is deprecated.

The Regex dispatchtype (L<Catalyst::DispatchType::Regex>) has been deprecated.

You are encouraged to move your application to Chained dispatch (L<Catalyst::DispatchType::Chained>).

If you cannot do so, please add a dependency to Catalyst::DispatchType::Regex to your application's
Makefile.PL

=head1 Upgrading to Catalyst 5.9

The major change is that L<Plack>, a toolkit for using the L<PSGI>
specification, now replaces most of the subclasses of L<Catalyst::Engine>. If
you are using one of the standard subclasses of L<Catalyst::Engine> this
should be a straightforward upgrade for you. It was a design goal for
this release to preserve as much backwards compatibility as possible.
However, since L<Plack> is different from L<Catalyst::Engine>, it is
possible that differences exist for edge cases. Therefore, we recommend
that care be taken with this upgrade and that testing should be greater
than would be the case with a minor point update. Please inform the
Catalyst developers of any problems so that we can fix them and
incorporate tests.

It is highly recommended that you become familiar with the L<Plack> ecosystem
and documentation. Being able to take advantage of L<Plack> development and
middleware is a major bonus to this upgrade. Documentation about how to
take advantage of L<Plack::Middleware> by writing your own C<< .psgi >> file
is contained in L<Catalyst::PSGI>.

If you have created a custom subclass of L<Catalyst:Engine>, you will
need to convert it to be a subclass of L<Plack::Handler>.

If you are using the L<Plack> engine, L<Catalyst::Engine::PSGI>, this new
release supersedes that code.

If you are using a subclass of L<Catalyst::Engine> that is aimed at
nonstandard or internal/testing uses, such as
L<Catalyst::Engine::Embeddable>, you should still be able to continue
using that engine.

Advice for specific subclasses of L<Catalyst::Engine> follows:

=head2 Upgrading the FastCGI Engine

No upgrade is needed if your myapp_fastcgi.pl script is already upgraded
to use L<Catalyst::Script::FastCGI>.

=head2 Upgrading the mod_perl / Apache Engines

The engines that are built upon the various iterations of mod_perl,
L<Catalyst::Engine::Apache::MP13> (for mod_perl 1, and Apache 1.x) and