add the init_meta thing to ::Delta
[gitmo/Moose.git] / lib / Moose / Manual / Delta.pod
index 7ecb2f1..a804cd2 100644 (file)
@@ -9,8 +9,9 @@ __END__
 =head1 DESCRIPTION
 
 This documents any important or noteworthy changes in Moose, with a
-focus on backwards. This does duplicate data from the F<Changes> file,
-but aims to provide more details and when possible workarounds.
+focus on things that affect backwards compatibility. This does duplicate data
+from the F<Changes> file, but aims to provide more details and when possible
+workarounds.
 
 Besides helping keep up with changes, you can also use this document
 for finding the lowest version of Moose that supported a given
@@ -18,7 +19,134 @@ 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
+=head1 2.0600
+
+=over 4
+
+=item C<< ->init_meta >> is even less reliable at loading extensions
+
+Previously, calling C<< MooseX::Foo->init_meta(@_) >> (and nothing else) from
+within your own C<init_meta> had a decent chance of doing something useful.
+This was never supported behavior, and didn't always work anyway. Due to some
+implementation adjustments, this now has a smaller chance of doing something
+useful, which could break code that was expecting it to continue doing useful
+things. Code that does this should instead just call
+C<< MooseX::Foo->import({ into => $into }) >>.
+
+=item All the Cookbook recipes have been renamed
+
+We've given them all descriptive names, rather than numbers. This makes it
+easier to talk about them, and eliminates the need to renumber recipes in
+order to reorder them or delete one.
+
+=back
+
+=head1 2.0400
+
+=over 4
+
+=item The parent of a union type is its components' nearest common ancestor
+
+Previously, union types considered all of their component types their parent
+types. This was incorrect because parent types are defined as types that must
+be satisfied in order for the child type to be satisfied, but in a union,
+validating as any parent type will validate against the entire union. This has
+been changed to find the nearest common ancestor for all of its components. For
+example, a union of "Int|ArrayRef[Int]" now has a parent of "Defined".
+
+=item Union types consider all members in the C<is_subtype_of> and C<is_a_type_of> methods
+
+Previously, a union type would report itself as being of a subtype of a type if
+I<any> of its member types were subtypes of that type. This was incorrect
+because any value that passes a subtype constraint must also pass a parent
+constraint. This has changed so that I<all> of its member types must be a
+subtype of the specified type.
+
+=item Enum types now work with just one value
+
+Previously, an C<enum> type needed to have two or more values.  Nobody knew
+why, so we fixed it.
+
+=item Methods defined in UNIVERSAL now appear in the MOP
+
+Any method introspection methods that look at methods from parent classes now
+find methods defined in UNIVERSAL. This includes methods like C<<
+$class->get_all_methods >> and C<< $class->find_method_by_name >>.
+
+This also means that you can now apply method modifiers to these methods.
+
+=item Hand-optimized type constraint code causes a deprecation warning
+
+If you provide an optimized sub ref for a type constraint, this now causes a
+deprecation warning. Typically, this comes from passing an C<optimize_as>
+parameter to C<subtype>, but it could also happen if you create a
+L<Moose::Meta::TypeConstraint> object directly.
+
+Use the inlining feature (C<inline_as>) added in 2.0100 instead.
+
+=item C<Class::Load::load_class> and C<is_class_loaded> have been removed
+
+The C<Class::MOP::load_class> and C<Class::MOP::is_class_loaded> subroutines
+are no longer documented, and will cause a deprecation warning in the
+future. Moose now uses L<Class::Load> to provide this functionality, and you
+should do so as well.
+
+=back
+
+=head1 2.0205
+
+=over 4
+
+=item Array and Hash native traits provide a C<shallow_clone> method
+
+The Array and Hash native traits now provide a "shallow_clone" method, which
+will return a reference to a new container with the same contents as the
+attribute's reference.
+
+=back
+
+=head1 2.0200
+
+=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.0300 release.
+
+=back
+
+=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
 
@@ -44,6 +172,102 @@ C<role_metaroles> option, as in:
         },
     );
 
+=item Class::MOP has been folded into the Moose dist
+
+Moose and Class::MOP are tightly related enough that they have always had to be
+kept pretty closely in step in terms of versions. Making them into a single
+dist should simplify the upgrade process for users, as it should no longer be
+possible to upgrade one without the other and potentially cause issues. No
+functionality has changed, and this should be entirely transparent.
+
+=item Moose's conflict checking is more robust and useful
+
+There are two parts to this. The most useful one right now is that Moose will
+ship with a C<moose-outdated> script, which can be run at any point to list the
+modules which are installed that conflict with the installed version of Moose.
+After upgrading Moose, running C<moose-outdated | cpanm> should be sufficient
+to ensure that all of the Moose extensions you use will continue to work.
+
+The other part is that Moose's C<META.json> file will also specify the
+conflicts under the C<x_conflicts> key. We are working with the Perl tool chain
+developers to try to get conflicts support added to CPAN clients, and if/when
+that happens, the metadata already exists, and so the conflict checking will
+become automatic.
+
+=item Most deprecated APIs/features are slated for removal in Moose 2.0200
+
+Most of the deprecated APIs and features in Moose will start throwing an error
+in Moose 2.0200. Some of the features will go away entirely, and some will
+simply throw an error.
+
+The things on the chopping block are:
+
+=over 8
+
+=item * Old public methods in Class::MOP and Moose
+
+This includes things like C<< Class::MOP::Class->get_attribute_map >>, C<<
+Class::MOP::Class->construct_instance >>, and many others. These were
+deprecated in L<Class::MOP> 0.80_01, released on April 5, 2009.
+
+These methods will be removed entirely in Moose 2.0200.
+
+=item * Old public functions in Class::MOP
+
+This include C<Class::MOP::subname>, C<Class::MOP::in_global_destruction>, and
+the C<Class::MOP::HAS_ISAREV> constant. The first two were deprecated in 0.84,
+and the last in 0.80. Class::MOP 0.84 was released on May 12, 2009.
+
+These functions will be removed entirely in Moose 2.0200.
+
+=item * The C<alias> and C<excludes> option for role composition
+
+These were renamed to C<-alias> and C<-excludes> in Moose 0.89, released on
+August 13, 2009.
+
+Passing these will throw an error in Moose 2.0200.
+
+=item * The old L<Moose::Util::MetaRole> API
+
+This include the C<apply_metaclass_roles()> function, as well as passing the
+C<for_class> or any key ending in C<_roles> to C<apply_metaroles()>. This was
+deprecated in Moose 0.93_01, released on January 4, 2010.
+
+These will all throw an error in Moose 2.0200.
+
+=item * Passing plain lists to C<type()> or C<subtype()>
+
+The old API for these functions allowed you to pass a plain list of parameter,
+rather than a list of hash references (which is what C<as()>, C<where>,
+etc. return). This was deprecated in Moose 0.71_01, released on February 22,
+2009.
+
+This will throw an error in Moose 2.0200.
+
+=item * The Role subtype
+
+This subtype was deprecated in Moose 0.84, released on June 26, 2009.
+
+This will be removed entirely in Moose 2.0200.
+
+=back
+
+=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 releases, we will still make minor releases to add new
+features, fix bugs, update documentation, etc.
+
 =back
 
 =head1 1.16