205 lines
6.7 KiB
Plaintext
205 lines
6.7 KiB
Plaintext
# 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.2207
|
|
|
|
=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@cpan.org>
|
|
|
|
=item *
|
|
|
|
Dave Rolsky <autarch@urth.org>
|
|
|
|
=item *
|
|
|
|
Jesse Luehrs <doy@cpan.org>
|
|
|
|
=item *
|
|
|
|
Shawn M Moore <sartak@cpan.org>
|
|
|
|
=item *
|
|
|
|
יובל קוג'מן (Yuval Kogman) <nothingmuch@woobling.org>
|
|
|
|
=item *
|
|
|
|
Karen Etheridge <ether@cpan.org>
|
|
|
|
=item *
|
|
|
|
Florian Ragwitz <rafl@debian.org>
|
|
|
|
=item *
|
|
|
|
Hans Dieter Pearcey <hdp@cpan.org>
|
|
|
|
=item *
|
|
|
|
Chris Prather <chris@prather.org>
|
|
|
|
=item *
|
|
|
|
Matt S Trout <mstrout@cpan.org>
|
|
|
|
=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
|