We're not doing weekly minor releases
[gitmo/Moose.git] / 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 =over 4
13
14 =item 1.
15
16 Moose favors correctness over everything.
17
18 =item 2.
19
20 Moose supports documented and tested behavior, not accidental behavior or side
21 effects.
22
23 =back
24
25 If a behavior has never been documented or tested, the behavior is
26 I<officially> undefined. Relying upon undocumented and untested behavior is
27 done at your own risk.
28
29 If a behavior is documented or tested but found to be incorrect later, the
30 behavior will go through a deprecation period. During the deprecation period,
31 use of that feature will cause a warning. Eventually, the deprecated feature
32 will be removed.
33
34 =head1 RELEASE SCHEDULE
35
36 Moose is on a system of quarterly major releases, with minor releases as
37 needed between major releases. A minor release is defined as one that makes
38 every attempt to preserve backwards compatibility. Currently this means that
39 we did not introduce any new dependency conflicts, and that we did not make
40 any changes to documented, tested behavior. A minor release can include new
41 features and bug fixes.
42
43 Major releases may be backwards incompatible. Moose prioritizes
44 correctness over backwards compatibility or performance; see the L<Deprecation
45 Policy> to understand how backwards incompatible changes are announced.
46
47 Before a major release, a series of development releases will be made so that
48 users can test the upcoming major release before it is distributed to CPAN. It
49 is in the best interests of everyone involved if these releases are tested as
50 widely as possible.
51
52 =head1 DEPRECATION POLICY
53
54 Moose has always prioritized correctness over performance and backwards
55 compatibility.
56
57 Major deprecations or API changes are documented in the Changes file as well
58 as in L<Moose::Manual::Delta>. The Moose developers will also make an effort
59 to warn users of upcoming deprecations and breakage through the Moose blog
60 (http://blog.moose.perl.org).
61
62 Deprecated APIs will be preserved for at least one year I<after the major
63 release which deprecates that API>. Deprecated APIs will only be removed in a
64 major release.
65
66 Moose will also warn during installation if the version of Moose being
67 installed will break an installed dependency. Unfortunately, due to the nature
68 of the Perl install process these warnings may be easy to miss.
69
70 =head1 BACKWARDS COMPATIBILITY
71
72 We try to ensure compatibility by having a extensive test suite (last
73 count just over around 5123 tests), as well as testing a number of
74 packages (currently just under 100 packages) that depend on Moose before
75 any release.
76
77 The current list of downstream dependencies that are tested is in
78 C<xt/author/test-my-dependents.t>.
79
80 =head1 VERSION NUMBERS
81
82 Moose version numbers consist of three parts, in the form X.YYZZ. The X is the
83 "special magic number" that only gets changed for really big changes. Think of
84 this as being like the "5" in Perl 5.12.1.
85
86 The YY portion is the major version number. Moose uses even numbers for stable
87 releases, and odd numbers for trial releases. The ZZ is the minor version, and
88 it simply increases monotonically. It starts at "00" each time a new major
89 version is released.
90
91 Semantically, this means that any two releases which share a major version
92 should be API-compatible with each other. In other words, 2.0200, 2.0201, and
93 2.0274 are all API-compatible.
94
95 Prior to version 2.0, Moose version numbers were monotonically incrementing
96 two decimal values (0.01, 0.02, ... 1.11, 1.12, etc.).
97
98 Moose was declared production ready at version 0.18 (via L<<
99 http://www.perlmonks.org/?node_id=608144 >>).
100
101 =head1 CONTRIBUTING
102
103 Moose has an open contribution policy. Anybody is welcome to submit a
104 patch. Please see L<Moose::Manual::Contributing> for more details.
105
106 =cut