lib/Moose/Manual/Support.pod

   1 package Moose::Manual::Support
   2
   3 # ABSTRACT: Policies regarding support, releases, and compatibility.
   4
   5 __END__
   6
   7 =pod
   8
   9 =head1 SUPPORT POLICY
  10
  11 There are two principles to Moose's policy of supported behavior.
  12
  13 =over 4
  14
  15 =item 1.
  16
  17 Moose favors correctness over everything.
  18
  19 =item 2.
  20
  21 Moose supports documented and tested behavior, not accidental behavior or side
  22 effects.
  23
  24 =back
  25
  26 If a behavior has never been documented or tested, the behavior is
  27 I<officially> undefined. Relying upon undocumented and untested behavior is
  28 done at your own risk.
  29
  30 If a behavior is documented or tested but found to be incorrect later, the
  31 behavior will go through a deprecation period. During the deprecation period,
  32 use of that feature will cause a warning. Eventually, the deprecated feature
  33 will be removed.
  34
  35 In some cases, it is not possible to deprecate a behavior. In this case, the
  36 behavior will simply be changed in a major release.
  37
  38 =head1 RELEASE SCHEDULE
  39
  40 Moose is on a system of quarterly major releases, with minor releases as
  41 needed between major releases. A minor release is defined as one that makes
  42 every attempt to preserve backwards compatibility. Currently this means that we
  43 did not introduce any new dependency conflicts, and that we did not make any
  44 changes to documented or tested behavior (this typically means that minor
  45 releases will not change any existing tests in the test suite, although they
  46 can add new ones). A minor release can include new features and bug fixes.
  47
  48 Major releases may be backwards incompatible. Moose prioritizes
  49 correctness over backwards compatibility or performance; see the L<DEPRECATION
  50 POLICY> to understand how backwards incompatible changes are announced.
  51
  52 Major releases are scheduled to happen during fixed release windows. If the
  53 window is missed, then there will not be a major release until the next
  54 release window. The release windows are one month long, and occur during the
  55 months of January, April, July, and October.
  56
  57 Before a major release, a series of development releases will be made so that
  58 users can test the upcoming major release before it is distributed to CPAN. It
  59 is in the best interests of everyone involved if these releases are tested as
  60 widely as possible.
  61
  62 =head1 DEPRECATION POLICY
  63
  64 Moose has always prioritized correctness over performance and backwards
  65 compatibility.
  66
  67 Major deprecations or API changes are documented in the Changes file as well
  68 as in L<Moose::Manual::Delta>. The Moose developers will also make an effort
  69 to warn users of upcoming deprecations and breakage through the Moose blog
  70 (http://blog.moose.perl.org).
  71
  72 Deprecated APIs will be preserved for at least one year I<after the major
  73 release which deprecates that API>. Deprecated APIs will only be removed in a
  74 major release.
  75
  76 Moose will also warn during installation if the version of Moose being
  77 installed will break an installed dependency. Unfortunately, due to the nature
  78 of the Perl install process these warnings may be easy to miss.
  79
  80 =head1 BACKWARDS COMPATIBILITY
  81
  82 We try to ensure compatibility by having a extensive test suite (last
  83 count just over around 5123 tests), as well as testing a number of
  84 packages (currently just under 100 packages) that depend on Moose before
  85 any release.
  86
  87 The current list of downstream dependencies that are tested is in
  88 C<xt/author/test-my-dependents.t>.
  89
  90 =head1 VERSION NUMBERS
  91
  92 Moose version numbers consist of three parts, in the form X.YYZZ. The X is the
  93 "special magic number" that only gets changed for really big changes. Think of
  94 this as being like the "5" in Perl 5.12.1.
  95
  96 The YY portion is the major version number. Moose uses even numbers for stable
  97 releases, and odd numbers for trial releases. The ZZ is the minor version, and
  98 it simply increases monotonically. It starts at "00" each time a new major
  99 version is released.
 100
 101 Semantically, this means that any two releases which share a major version
 102 should be API-compatible with each other. In other words, 2.0200, 2.0201, and
 103 2.0274 are all API-compatible.
 104
 105 Prior to version 2.0, Moose version numbers were monotonically incrementing
 106 two decimal values (0.01, 0.02, ... 1.11, 1.12, etc.).
 107
 108 Moose was declared production ready at version 0.18 (via L<<
 109 http://www.perlmonks.org/?node_id=608144 >>).
 110
 111 =head1 PERL VERSION COMPATIBILITY
 112
 113 As of version 2.00, Moose officially supports being run on perl 5.8.3+. Our
 114 current policy is to support the earliest version of Perl shipped in the latest
 115 stable release of any major operating system (this tends to mean CentOS). We
 116 will provide at least six months notice (two major releases) when we decide to
 117 increase the officially supported Perl version. The next time this will happen
 118 is in January of 2012, when Moose 2.06 will increase the minimum officially
 119 supported Perl version to 5.10.1.
 120
 121 "Officially supported" does not mean that these are the only versions of Perl
 122 that Moose will work with. Our declared perl dependency will remain at 5.8.3 as
 123 long as our test suite continues to pass on 5.8.3. What this does mean is that
 124 the core Moose dev team will not be spending any time fixing bugs on versions
 125 that aren't officially supported, and new contributions will not be rejected
 126 due to being incompatible with older versions of perl except in the most
 127 trivial of cases. We will, however, still welcome patches to make Moose
 128 compatible with earlier versions, if other people are still interested in
 129 maintaining compatibility. Note that although performance regressions are
 130 acceptable in order to maintain backwards compatibility (as long as they only
 131 affect the older versions), functionality changes and buggy behavior will not
 132 be. If it becomes impossible to provide identical functionality between modern
 133 Perl versions and unsupported Perl versions, we will increase our declared perl
 134 dependency instead.
 135
 136 =head1 CONTRIBUTING
 137
 138 Moose has an open contribution policy. Anybody is welcome to submit a
 139 patch. Please see L<Moose::Manual::Contributing> for more details.
 140
 141 =cut