=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
it documented here, or think we missed an important feature, please
send us a patch.
+=head1 2.0500
+
+=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.
+
+=head1 2.0300
+
+=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.0100
+
+=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
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, release on April 5, 2009.
+deprecated in L<Class::MOP> 0.80_01, released on April 5, 2009.
These methods will be removed entirely in Moose 2.0200.
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
+In between major releases, we will still make minor releases to add new
features, fix bugs, update documentation, etc.
=back