Moose 1.15 will be out the door shortly (he says with hope in his heart), and it will include a few incompatibilities along with some bug fixes and speedups.
It's worthwhile to discuss both the philosophy and actual practice of backwards compatibility in Moose, so end users know what to expect.
There are a couple principles at work.
- Moose favors correctness over backwards compatibility.
- Moose supports documented behavior, not accidental behavior or side effects.
These two principles are often related.
In this next release, methods generated by using a native trait will now check their arguments. If you try to pass an argument to an Array's count() method, it will throw an error.
We never documented this one way or another, and the current behavior is clearly wrong, so we feel that changing this is okay.
When incorrect behavior is documented, we don't remove it outright if we can possibly avoid it. Instead, we add a deprecation warning, and will remove it eventually.
This stands in contrast to other projects, like Catalyst, which has a much stronger backwards compatibility guarantee.
So that's the policy, but how about the practice?
We do a lot of testing to smoke these changes. A while back, I wrote a module called Test::DependentModules which allows you to test some or all of the modules dependent on a given module. While we don't test every dependent, since lots of them are stale, we do test quite a few. If you have something on CPAN you'd like to include in the tests, just let us know via irc or email.
When this test finds a problem with a change, we usually offer to help downstream authors change their code, and we try to synchronize new releases of Moose with new releases of dependents. It's most often MooseX modules which get broken, because many of them are intimate with the Moose internals. It's less common for modules which simply use Moose to break outright.
Fey::ORM is effectively a MooseX module, despite the name, as are a few others. Some modules, like Catalyst, poke around in the more arcane corners of Moose, and tend to be more easily broken.
We also maintain a list of conflicting module versions by hand in our Makefile.PL. Unfortunately, the CPAN toolchain doesn't (yet?) have any sort of real support for conflict handling, so all we can do is print out some warnings to the terminal at install time. I hope that in the future, there will be an official way to declare conflicts. Then CPAN clients can let the user choose how to handle them (update the conflicting module, ignore, don't install the new Moose).
Finally, we expect that end users test new versions of Moose (and of any other dependency) before deploying to production. If you don't have testing that you trust, you probably shouldn't be upgrading at all!
This is also documented in the Moose docs, but with less detail.
Hopefully this helps make our decisions a little more transparent. Comments (sans too much flame) are welcome.
