A complaint that has come up multiple times over the past few months is that, as important as Moose is becoming in the Perl ecosystem, it should be more concerned with backwards compatibility. After a series of discussions, the Moose development team has come up with a support policy that seems to satisfy most people; you can read about it here. The main points are: Moose will be moving to a time-boxed release cycle of three months between (major) releases. Bug fixes and minor features can be added in between major releases as long as they don't break backwards compatibility (and we will put more effort into making sure they don't). Major releases can break backwards compatibility, but we will release at least one (ideally more than one) trial release before the actual release comes out, so that people can test their own systems with the new features, and report back with issues they may have. We will also do our best to assist maintainers of Moose extensions with updating their modules for major changes, but not to the point of taking over maintainership of extensions that have become unmaintained. If you rely on a Moose extension whose maintainer has abandoned it, feel free to find someone willing to take up maintainership, and come talk to us on #moose, we'll be more than willing to help you get up to speed.
Now, on to the fun part(: The next Moose release will contain several exciting new improvements, both for users and extension authors. The first is that there has been a significant effort to speed up Moose's compilation time, through several means. The largest and most obvious is that Package::Stash, the module that Moose uses to do its symbol table manipulation (for adding and retrieving methods, among other things), has been rewritten entirely in XS. Since Moose spends over a third of its compilation time doing symbol table manipulation, this seemed like a good optimization target, and this turns out to have been correct - it resulted in a 10-15% speedup across the board for Moose application compile times. Another advantage to this is that it fixes a couple (admittedly minor) long-standing bugs in the Class::MOP::Package API, since the symbol table API available from pure perl has several inherent issues itself. Another area that should see significant improvement is in code which uses the native delegation attribute traits. Previously (ever since the rewrite in 1.15), the traits themselves were loaded lazily (i.e. Moose::Meta::Attribute::Native::Trait::Bool wasn't loaded unless you actually declared an attribute with traits => ['Bool']), but the implementations of each native delegation were all loaded at once, when the trait itself was loaded. This has been fixed, and should be another fairly large speedup for applications which use only a couple native delegations from the traits they use (which is the case the vast majority of the time). Finally, the way method metaobjects are cached has been improved, which speeds up the introspection of methods (which happens frequently during compilation) a small but noticeable amount. Here are some links to some relevant profiling data (run on my netbook under full profiling, which is why the times are so high): "perl -MKiokuDB -e1" with Moose 1.19: 8.60s, "perl -MKiokuDB -e1" with Moose git: 6.38s, "perl -MMarkdent::Simple::Document -e1" with Moose 1.19: 13.9s, "perl -MMarkdent::Simple::Document -e1" with Moose git: 10.6s. These changes should have minimal compatibility impact (and none at all if you don't use the Class::MOP::Package API); a more detailed discussion is in Moose::Manual::Delta.
In terms of features, we have made a fairly significant change to how attribute metaroles work. Previously, when a role was applied to a class, it would copy the attributes from the role into the class using the class's default attribute metaclass, prior to applying the traits specified in the attribute definition. This is obviously incorrect with a bit of thought - attribute metaclasses completely define how the attribute works, including things like how accessors are generated. If a role contains an attribute and some methods, those methods need to be able to know what method name the accessor is going to be installed under, or the role won't work. A good example of this is a class which uses MooseX::FollowPBP consuming a role which doesn't - currently, this completely breaks the role. With this change, roles now have their own default attribute metaclass, separate from any class. This also allows for an additional feature - when writing extensions, you can specify the 'applied_attribute' option to the 'role' block in 'apply_metaroles' to specify a set of default traits that all attributes defined in that role will receive when they are applied to a class. This should work identically to the 'attribute' option in the 'class' block, and should allow extensions which add default attribute metaroles (such as MooseX::Aliases) to work identically in both classes and roles (unlike currently, where the trait must be applied explicitly in role attributes). The downside to this is that it breaks backwards compatibility in a potentially confusing way: if you were assuming and relying on role attributes using the class's attribute metaclass, your roles will break, and there isn't really a way to detect this. The solution will be to use the same extensions in your roles that you do in the classes that consume those roles, but as noted previously, attribute metaroles don't currently work in roles. These extensions will be fixed by the time we make an actual release.
Finally, there is also some good news for extension authors: the inlining API should be much more sane, and the code itself should be much more readable, so adding inlined method generation support to your modules which affect accessor or constructor/destructor generation should be much, much easier now. Some highlights include: the attribute metaclass and class metaclass controlling entirely how the bodies of the methods they generate are created (so there should no longer be a need to write accessor or constructor metaclass traits), accessor generation in Class::MOP and Moose going through one much simplified codepath (read: removed the obscene amount of code duplication between Class::MOP and Moose), so figuring out how a given accessor is generated should be pretty trivial now, and constructors now asking the attribute metaclass how to initialize attributes at construction time, rather than doing it themselves with a bunch of duplicated code (so in the case of simple attribute traits which affect accessor generation, manually modifying the constructor generation shouldn't even be necessary). The downside to this is, as you may have guessed, the API for doing code inlining has been changed pretty radically. This will require some work on the part of extension authors, in order to use the new API (since there's not really a non-insane way to support both APIs), but again, we'll be working with extension authors to make sure this happens before our actual release, and we'll be releasing a few dev releases prior to the actual release to allow people with non-CPAN code to have a chance to update their code.
As far as a plan goes, we're looking to have our first trial release out by the end of this month, and are aiming for the actual release to happen sometime in late December or early January. If you have any questions about the new release and support process, or about any of these new features, definitely let us know - we're very open to feedback, either here, on the Moose mailing list, or on #moose-dev on IRC.