Fix code example to match current api
[gitmo/Moose.git] / lib / Moose / Manual / Support.pod
index 5c6ee5d..80106be 100644 (file)
@@ -1,9 +1,10 @@
-=pod
+package Moose::Manual::Support
 
-=head1 NAME
+# ABSTRACT: Policies regarding support, releases, and compatibility.
 
-Moose::Manual::Support - Policies regarding support, releases, and
-compatibility.
+__END__
+
+=pod
 
 =head1 SUPPORT POLICY
 
@@ -31,18 +32,28 @@ 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.
+
 =head1 RELEASE SCHEDULE
 
-Moose is on a system of weekly minor releases and quarterly major releases. A
-minor release is defined as one that makes every attempt to preserve backwards
-compatibility. Currently this means that we did not introduce any new
-dependency conflicts, and that we did not make any changes to documented,
-tested behavior. A minor release can include new features and bug fixes.
+Moose is on a system of quarterly major releases, with minor releases as
+needed between major releases. A minor release is defined as one that makes
+every attempt to preserve backwards compatibility. Currently this means that we
+did not introduce any new dependency conflicts, and that we did not make any
+changes to documented or tested behavior (this typically means that minor
+releases will not change any existing tests in the test suite, although they
+can add new ones). A minor release can include new features and bug fixes.
 
 Major releases may be backwards incompatible. Moose prioritizes
 correctness over backwards compatibility or performance; see the L<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
@@ -58,8 +69,9 @@ as in L<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. Of course, the
-removal of a deprecated API will only happen in a major release.
+Deprecated APIs will be preserved for at least one year I<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
@@ -96,6 +108,31 @@ two decimal values (0.01, 0.02, ... 1.11, 1.12, etc.).
 Moose was declared production ready at version 0.18 (via L<<
 http://www.perlmonks.org/?node_id=608144 >>).
 
+=head1 PERL VERSION COMPATIBILITY
+
+As of version 2.00, Moose officially supports being run on perl 5.8.3+. Our
+current policy is to support the earliest version of Perl shipped in the latest
+stable release of any major operating system (this tends to mean CentOS). We
+will provide at least six months notice (two major releases) when we decide to
+increase the officially supported Perl version. The next time this will happen
+is in January of 2012, when Moose 2.06 will increase the minimum officially
+supported Perl version to 5.10.1.
+
+"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. 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.
+
 =head1 CONTRIBUTING
 
 Moose has an open contribution policy. Anybody is welcome to submit a