X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Runtime.git;a=blobdiff_plain;f=lib%2FCatalyst%2FDelta.pod;h=985b5719e71368497463c824843c4c4dfd537cd1;hp=020d0e104961360e14f0c82d63d39909ef7c7cd3;hb=5bb2a5b3a3703b0eb12f6be0983e7f4676c55545;hpb=7df44a710bdab986255e0d63db58a8af478f1100

diff --git a/lib/Catalyst/Delta.pod b/lib/Catalyst/Delta.pod
index 020d0e1..985b571 100755
--- a/lib/Catalyst/Delta.pod
+++ b/lib/Catalyst/Delta.pod
@@ -1,8 +1,123 @@
-=head1 Deltachanges from 5.7 to 5.8
+=head1 NAME
 
-This is an overview of the user visible changes in 5.8.
+Catalyst::Delta - Overview of changes between versions of Catalyst
 
-=head2 Deprecations
+=head1 DESCRIPTION
+
+This is an overview of the user-visible changes to Catalyst between major Catalyst releases.
+
+=head2 VERSION 5.90053
+
+We are now clarifying the behavior of log, plugins and configuration during
+the setup phase.  Since Plugins might require a log during setup, setup_log
+must run BEFORE setup_plugins.   This has the unfortunate side effect that
+anyone using the popular ConfigLoader plugin will not be able to supply
+configuration to custom logs since the configuration is not yet finalized
+when setup_log is run (when using ConfigLoader, which is a plugin and is
+not loaded until later.)
+
+As a workaround, you can supply custom log configuration directly into
+the configuration:
+
+    package MyApp;
+    use Catalyst;
+
+    __PACKAGE__->config(
+      my_custom_log_info => { %custom_args },
+    );
+
+    __PACKAGE__->setup;
+
+If you wish to configure the custom logger differently based on ENV, you can
+try:
+
+    package MyApp;
+
+    use Catalyst;
+    use Catalyst::Utils;
+
+    __PACKAGE__->config(
+      Catalyst::Utils::merge_hashes(
+        +{ my_custom_log_info => { %base_custom_args } },
+        +{ do __PACKAGE__->path_to( $ENV{WHICH_CONF}."_conf.pl") },
+      ),
+    );
+
+    __PACKAGE__->setup;
+
+Or create a standalone Configuration class that does the right thing.
+
+Basically if you want to configure a logger via Catalyst global configuration
+you can't use ConfigLoader because it will always be loaded too late to be of
+any use.  Patches and workaround options welcomed!
+
+=head2 VERSION 5.9XXXX 'cataplack'
+
+The Catalyst::Engine sub-classes have all been removed and deprecated,
+to be replaced with Plack handlers.
+
+Plack is an implementation of the L<PSGI> specification, which is
+a standard interface between web servers and application frameworks.
+
+This should be no different for developers, and you should not have to
+migrate your applications unless you are using a custom engine already.
+
+This change benefits Catalyst significantly by reducing the amount of
+code inside the framework, and means that the framework gets upstream
+bug fixes in L<Plack>, and automatically gains support for any web server
+which a L<PSGI> compliant handler is written for.
+
+It also allows you more flexibility with your application, and allows
+the use of cross web framework 'middleware'.
+
+Developers are recommended to read L<Catalyst::Upgrading> for notes about
+upgrading, especially if you are using an unusual deployment method.
+
+Documentation for how to take advantage of L<PSGI> can be found in
+L<Catalyst::PSGI>, and information about deploying your application
+has been moved to L<Catalyst::Manual::Deployment>.
+
+=head3 Updated modules:
+
+A number of modules have been updated to pass their tests or not
+produce deprecation warnings with the latest version of Catalyst.
+It is recommended that you upgrade any of these that you are using
+after installing this version of Catalyst.
+
+These extensions are:
+
+=over
+
+=item L<Catalyst::Engine::HTTP::Prefork>
+
+This is now deprecated, see L<Catalyst::Upgrading>.
+
+=item L<Test::WWW::Mechanize::Catalyst>
+
+Has been updated to not produce deprecation warnings, upgrade recommended.
+
+=item Catalyst::ActionRole::ACL
+
+Has been updated to fix failing tests (although older versions still
+function perfectly with this version of Catalyst).
+
+=item Catalyst::Plugin::Session::Store::DBIC
+
+Has been updated to fix failing tests (although older versions still
+function perfectly with this version of Catalyst).
+
+=item Catalyst::Plugin::Authentication
+
+Has been updated to fix failing tests (although older versions still
+function perfectly with this version of Catalyst).
+
+=back
+
+=head1 PREVIOUS VERSIONS
+
+=head2 VERSION 5.8XXXX 'catamoose'
+
+=head3 Deprecations
 
 Please see L<Catalyst::Upgrading> for a full description of how changes in the
 framework may affect your application.
@@ -25,7 +140,7 @@ Below is a brief list of features which have been deprecated in this release:
 
 =back
 
-=head2 New features
+=head3 New features
 
 =head3 Dispatcher
 
@@ -78,7 +193,9 @@ L<IO::Handle>.
 
 Added code method as an alias for C<< $res->status >>
 
-=head2 Consequences of the Moose backend
+=back
+
+=head3 Consequences of the Moose back end
 
 =over
 
@@ -95,7 +212,7 @@ classes are better implemented as Moose roles.
 
 =item *
 
-L<MooseX::MethodAttributes::Inheritable> is used to contain action
+L<MooseX::MethodAttributes::Role::AttrContainer::Inheritable> is used to contain action
 attributes. This means that attributes are represented in the MOP, and
 decouples action creation from attributes.
 
@@ -103,7 +220,7 @@ decouples action creation from attributes.
 
 There is a reasonable API in Catalyst::Controller for working with
 and registering actions, allowing a controller sub-class to replace
-subroutine attributes for action declerations with an alternate
+subroutine attributes for action declarations with an alternate
 syntax.
 
 =item *
@@ -118,13 +235,13 @@ Your application class is forced to become immutable at the end of compilation.
 
 =back
 
-=head2 Bug fixes
+=head3 Bug fixes
 
 =over
 
 =item *
 
-Don't ignore SIGCHLD while handling requests with the dev server, so that
+Don't ignore SIGCHLD while handling requests with the development server, so that
 system() and other ways of creating child processes work as expected.
 
 =item *