lib/Moose/Manual/Support.pod

   1 =pod
   2
   3 =head1 NAME
   4
   5 Moose::Manual::Support - Policies regarding support, releases, and
   6 compatibility.
   7
   8 =head1 SUPPORT POLICY
   9
  10 There are two principles to Moose's Policy of Supported Behavior
  11
  12 1. Moose favors correctness over everything.
  13 2. Moose supports documented and tested behavior, not accidental behavior or side effects.
  14
  15 If a behavior has never been documented or tested, the behavior is I<officially> undefined. Relying
  16 upon undocumented and untested behavior is done at your own risk.
  17
  18 If a behavior is documented or tested but found to be incorrect later, the behavior will go through a
  19 deprecation period in which it warns before being removed.
  20
  21 =head1 RELEASE SCHEDULE
  22
  23 Moose uses the release early, release often philosophy.
  24
  25 Moose is on a system of weekly minor releases, and quarterly major releases. A minor release is
  26 deifined as one that makes every attempt to not break backwards compatibility. Currently this means
  27 that the dependency conflict lists, and test suite did not change substantially, or that any changes
  28 were additive.
  29
  30 Major releases are potentially backwards incompatibiliy. Moose prioritizes correcness over backwards
  31 compatibility or performance, see the Deprecation Policy below for how backwards incompatible changes
  32 are announced.
  33
  34 Before a major release, a series of Development Releases will be made so that users can test the
  35 upcoming major release before it is distributed to CPAN. It is in the best interests of everyone
  36 involved if these releases are tested as widely as possible.
  37
  38 =head1 DEPRECATION POLICY
  39
  40 Moose has always prioritized correctness over performance and backwards
  41 compatibility.
  42
  43 Major deprecations or API changes are first documented in the Changes
  44 file as well as in L<Moose::Manual::Delta>.
  45
  46 Moose then attempts to warn for deprecated features and API changes for
  47 a reasonable number of releases before breaking any tested API.
  48
  49 Moose will also warn during installation if the version being installed
  50 will break a known installed dependency. Unfortunately due to the nature
  51 of the Perl install process these warnings may be easy to miss.
  52
  53 =head1 BACKWARDS COMPATIBILITY
  54
  55 We try to ensure compatibility by having a extensive test suite (last
  56 count just over around 5123 tests), as well as testing a number of
  57 packages (currently just under 100 packages) that depend on Moose before
  58 any release.
  59
  60 The current list of downstream dependencies that are tested is in
  61 C<xt/author/test-my-dependents.t>.
  62
  63 =head1 VERSION NUMBERS
  64
  65 Moose's version numbers are monotonically incrementing two decimal
  66 values. The version numbers in Moose are I<not> semantic. This means
  67 that version 1.00 will be the hundredth release, nothing more.
  68
  69 Occasionally, we will release a test release with a version like
  70 0.90_03. These versions may be less stable than non-test releases, and exist
  71 so that developers can test potentially code-breaking changes. By default, the
  72 CPAN client will not install a distribution which has an underscore in its
  73 version.
  74
  75 Moose was declared production ready at version 0.18 (via L<<
  76 http://www.perlmonks.org/?node_id=608144 >>).
  77
  78 =head1 CONTRIBUTING
  79
  80 Moose has an open contribution policy. Anybody is welcome to submit a
  81 patch. Please see L<Moose::Manual::Contributing> for more details.
  82
  83 =cut