summaryrefslogtreecommitdiff
path: root/lib/Moose/Manual/Support.pod
diff options
context:
space:
mode:
Diffstat (limited to 'lib/Moose/Manual/Support.pod')
-rw-r--r--lib/Moose/Manual/Support.pod204
1 files changed, 204 insertions, 0 deletions
diff --git a/lib/Moose/Manual/Support.pod b/lib/Moose/Manual/Support.pod
new file mode 100644
index 0000000..d4d48a6
--- /dev/null
+++ b/lib/Moose/Manual/Support.pod
@@ -0,0 +1,204 @@
+# PODNAME: Moose::Manual::Support
+# ABSTRACT: Policies regarding support, releases, and compatibility.
+
+__END__
+
+=pod
+
+=encoding UTF-8
+
+=head1 NAME
+
+Moose::Manual::Support - Policies regarding support, releases, and compatibility.
+
+=head1 VERSION
+
+version 2.1405
+
+=head1 SUPPORT POLICY
+
+There are two principles to Moose's policy of supported behavior.
+
+=over 4
+
+=item 1.
+
+Moose favors correctness over everything.
+
+=item 2.
+
+Moose supports documented and tested behavior, not accidental behavior or side
+effects.
+
+=back
+
+If a behavior has never been documented or tested, the behavior is
+I<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.
+
+=head1 RELEASE SCHEDULE
+
+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
+widely as possible.
+
+=head1 DEPRECATION POLICY
+
+Moose has always prioritized correctness over performance and backwards
+compatibility.
+
+Major deprecations or API changes are documented in the Changes file as well
+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 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
+of the Perl install process these warnings may be easy to miss.
+
+=head1 BACKWARDS COMPATIBILITY
+
+We try to ensure compatibility by having a extensive test suite (last count
+over 18000 tests), as well as testing a number of packages (currently just
+under 100 packages) that depend on Moose before any release.
+
+The current list of downstream dependencies that are tested is in
+C<xt/author/test-my-dependents.t>.
+
+=head1 VERSION NUMBERS
+
+Moose version numbers consist of three parts, in the form X.YYZZ. The X is the
+"special magic number" that only gets changed for really big changes. Think of
+this as being like the "5" in Perl 5.12.1.
+
+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 L<<
+http://www.perlmonks.org/?node_id=608144 >>).
+
+=head1 PERL VERSION COMPATIBILITY
+
+As of version 2.16, Moose will officially support being run on perl 5.10.1+. 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.
+
+"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.
+
+=head1 CONTRIBUTING
+
+Moose has an open contribution policy. Anybody is welcome to submit a
+patch. Please see L<Moose::Manual::Contributing> for more details.
+
+=head1 AUTHORS
+
+=over 4
+
+=item *
+
+Stevan Little <stevan.little@iinteractive.com>
+
+=item *
+
+Dave Rolsky <autarch@urth.org>
+
+=item *
+
+Jesse Luehrs <doy@tozt.net>
+
+=item *
+
+Shawn M Moore <code@sartak.org>
+
+=item *
+
+יובל קוג'מן (Yuval Kogman) <nothingmuch@woobling.org>
+
+=item *
+
+Karen Etheridge <ether@cpan.org>
+
+=item *
+
+Florian Ragwitz <rafl@debian.org>
+
+=item *
+
+Hans Dieter Pearcey <hdp@weftsoar.net>
+
+=item *
+
+Chris Prather <chris@prather.org>
+
+=item *
+
+Matt S Trout <mst@shadowcat.co.uk>
+
+=back
+
+=head1 COPYRIGHT AND LICENSE
+
+This software is copyright (c) 2006 by Infinity Interactive, Inc..
+
+This is free software; you can redistribute it and/or modify it under
+the same terms as the Perl 5 programming language system itself.
+
+=cut