Docs, Delta, and Changes for inline constraints

[gitmo/Moose.git] / lib / Moose / Manual / Delta.pod

diff --git a/lib/Moose/Manual/Delta.pod b/lib/Moose/Manual/Delta.pod
index feb0f6d..c76aff6 100644 (file)
--- a/lib/Moose/Manual/Delta.pod
+++ b/lib/Moose/Manual/Delta.pod
@@ -18,6 +18,45 @@ feature.  If you encounter a problem and have a solution but don't see
 it documented here, or think we missed an important feature, please
 send us a patch.
 
+=head1 $NEXT
+
+=over 4
+
+=item Hand-optimized type constraint code is deprecated in favor of inlining
+
+Moose allows you to provide a hand-optimized version of a type constraint's
+subroutine reference. This version allows type constraints to generate inline
+code, and you should use this inlining instead of providing a hand-optimized
+subroutine reference.
+
+This affects the C<optimize_as> sub exported by
+L<Moose::Util::TypeConstraints>. Use C<inline_as> instead.
+
+This will start warning in the 2.0200 release.
+
+=head1 2.0002
+
+=over 4
+
+=item More useful type constraint error messages
+
+If you have L<Devel::PartialDump> version 0.14 or higher installed, Moose's
+type constraint error messages will use it to display the invalid value, rather
+than just displaying it directly. This will generally be much more useful. For
+instance, instead of this:
+
+  Attribute (foo) does not pass the type constraint because: Validation failed for 'ArrayRef[Int]' with value ARRAY(0x275eed8)
+
+the error message will instead look like
+
+  Attribute (foo) does not pass the type constraint because: Validation failed for 'ArrayRef[Int]' with value [ "a" ]
+
+Note that L<Devel::PartialDump> can't be made a direct dependency at the
+moment, because it uses Moose itself, but we're considering options to make
+this easier.
+
+=back
+
 =head1 2.0000
 
 =over 4
@@ -126,6 +165,22 @@ This will be removed entirely in Moose 2.0200.
 
 =back
 
+=head1 1.21
+
+=over 4
+
+=item * New release policy
+
+As of the 2.0 release, Moose now has an official release and support policy,
+documented in L<Moose::Manual::Support>. All API changes will now go through a
+deprecation cycle of at least one year, after which the deprecated API can be
+removed. Deprecations and removals will only happen in major releases.
+
+In between major release, we will still make minor releases to add new
+features, fix bugs, update documentation, etc.
+
+=back
+
 =head1 1.16
 
 =over 4