[Catalyst-commits] r10137 - Catalyst-Runtime/5.80/trunk/lib/Catalyst

[t0m at dev.catalyst.perl.org]

Author: t0m
Date: 2009-05-13 22:37:33 +0000 (Wed, 13 May 2009)
New Revision: 10137

Modified:
   Catalyst-Runtime/5.80/trunk/lib/Catalyst/Upgrading.pod
Log:
Doc, add new upgrading caveat, and start what works on Moose docs for lack of a better place - should this be in ::ExtendingCatalyst?

Modified: Catalyst-Runtime/5.80/trunk/lib/Catalyst/Upgrading.pod
===================================================================
--- Catalyst-Runtime/5.80/trunk/lib/Catalyst/Upgrading.pod	2009-05-13 22:31:06 UTC (rev 10136)
+++ Catalyst-Runtime/5.80/trunk/lib/Catalyst/Upgrading.pod	2009-05-13 22:37:33 UTC (rev 10137)
@@ -18,8 +18,33 @@
 If you think you have found an upgrade related issue which is not covered in
 this document, then please email the Catalyst list to discuss the problem.
 
+=head1 Moose features
+
+=head2 Application class roles.
+
+You can only apply method modifiers after the applications C<< ->setup >>
+method has been called. This means that modifiers will not work with methods
+which run during the call to C<< ->setup >>.
+
+=head2 Controller actions in Moose roles
+
+Is known to not work.
+
 =head1 Known backwards compatibility breakages.
 
+=head2 Applications in a single file.
+
+Applications must be in their own file, and loaded at compile time. This
+issue generally only affects the tests of cpan distributions. Defining an
+application inline in a block, and using plugins which supply a C< new >
+method, then using that application latter in tests, within the same file
+will cause your application to fail.
+
+This is due to the fact that Catalyst is inlining a new method on your
+application class allowing it to be compatible with Moose. The method used
+to do this changed in 5.80004 to avoid the possibility of reporting
+'Unknown Error' if your application failed to compile.
+
 =head2 Issues with Class::C3
 
 Catalyst 5.80 uses L<Algorithm::C3> method dispatch order. This is built into