If a behavior has never been documented or tested, the behavior is officially undefined. Relying upon undocumented and untested behavior is done at your own risk.
If a behavior is documented or tested but found to be incorrect later, the behavior will go through a deprecation period. During the deprecation period, use of that feature will cause a warning. Eventually, the deprecated feature will be removed.
In some cases, it is not possible to deprecate a behavior. In this case, the behavior will simply be changed in a major release.
Major releases may be backwards incompatible. Moose prioritizes correctness over backwards compatibility or performance; see the DEPRECATION POLICY to understand how backwards incompatible changes are announced.
Major releases are scheduled to happen during fixed release windows. If the window is missed, then there will not be a major release until the next release window. The release windows are one month long, and occur during the months of January, April, July, and October.
Before a major release, a series of development releases will be made so that users can test the upcoming major release before it is distributed to CPAN. It is in the best interests of everyone involved if these releases are tested as widely as possible.
Major deprecations or API changes are documented in the Changes file as well as in Moose::Manual::Delta. The Moose developers will also make an effort to warn users of upcoming deprecations and breakage through the Moose blog (http://blog.moose.perl.org).
Deprecated APIs will be preserved for at least one year after the major release which deprecates that API. Deprecated APIs will only be removed in a major release.
Moose will also warn during installation if the version of Moose being installed will break an installed dependency. Unfortunately, due to the nature of the Perl install process these warnings may be easy to miss.
The current list of downstream dependencies that are tested is in "xt/author/test-my-dependents.t".
The YY portion is the major version number. Moose uses even numbers for stable releases, and odd numbers for trial releases. The ZZ is the minor version, and it simply increases monotonically. It starts at ``00'' each time a new major version is released.
Semantically, this means that any two releases which share a major version should be API-compatible with each other. In other words, 2.0200, 2.0201, and 2.0274 are all API-compatible.
Prior to version 2.0, Moose version numbers were monotonically incrementing two decimal values (0.01, 0.02, ... 1.11, 1.12, etc.).
Moose was declared production ready at version 0.18 (via <http://www.perlmonks.org/?node_id=608144>).
``Officially supported'' does not mean that these are the only versions of Perl that Moose will work with. Our declared perl dependency will remain at 5.8.3 as long as our test suite continues to pass on 5.8.3. What this does mean is that the core Moose dev team will not be spending any time fixing bugs on versions that aren't officially supported, and new contributions will not be rejected due to being incompatible with older versions of perl except in the most trivial of cases. We will, however, still welcome patches to make Moose compatible with earlier versions, if other people are still interested in maintaining compatibility. As such, the current minimum required version of 5.8.3 will remain for as long as downstream users are happy to assist with maintenance.
Note that although performance regressions are acceptable in order to maintain backwards compatibility (as long as they only affect the older versions), functionality changes and buggy behavior will not be. If it becomes impossible to provide identical functionality between modern Perl versions and unsupported Perl versions, we will increase our declared perl dependency instead.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.