+=encoding utf8
+
=head1 NAME
perlpolicy - Various and sundry policies and commitments related to the Perl core
policies about how the Perl 5 Porters collectively develop and maintain
the Perl core.
+=head1 GOVERNANCE
+
+=head2 Perl 5 Porters
+
+Subscribers to perl5-porters (the porters themselves) come in several flavours.
+Some are quiet curious lurkers, who rarely pitch in and instead watch
+the ongoing development to ensure they're forewarned of new changes or
+features in Perl. Some are representatives of vendors, who are there
+to make sure that Perl continues to compile and work on their
+platforms. Some patch any reported bug that they know how to fix,
+some are actively patching their pet area (threads, Win32, the regexp
+-engine), while others seem to do nothing but complain. In other
+words, it's your usual mix of technical people.
+
+Over this group of porters presides Larry Wall. He has the final word
+in what does and does not change in any of the Perl programming languages.
+These days, Larry spends most of his time on Perl 6, while Perl 5 is
+shepherded by a "pumpking", a porter responsible for deciding what
+goes into each release and ensuring that releases happen on a regular
+basis.
+
+Larry sees Perl development along the lines of the US government:
+there's the Legislature (the porters), the Executive branch (the
+-pumpking), and the Supreme Court (Larry). The legislature can
+discuss and submit patches to the executive branch all they like, but
+the executive branch is free to veto them. Rarely, the Supreme Court
+will side with the executive branch over the legislature, or the
+legislature over the executive branch. Mostly, however, the
+legislature and the executive branch are supposed to get along and
+work out their differences without impeachment or court cases.
+
+You might sometimes see reference to Rule 1 and Rule 2. Larry's power
+as Supreme Court is expressed in The Rules:
+
+=over 4
+
+=item 1
+
+Larry is always by definition right about how Perl should behave.
+This means he has final veto power on the core functionality.
+
+=item 2
+
+Larry is allowed to change his mind about any matter at a later date,
+regardless of whether he previously invoked Rule 1.
+
+=back
+
+Got that? Larry is always right, even when he was wrong. It's rare
+to see either Rule exercised, but they are often alluded to.
+
=head1 MAINTENANCE AND SUPPORT
Perl 5 is developed by a community, not a corporate entity. Every change
=item *
-We "officially" support the two most recent stable release
-series. As of the release of 5.14.0, we will "officially"
-end support for Perl 5.10, other than providing security
+We "officially" support the two most recent stable release series. 5.14.x
+and earlier are now out of support. As of the release of 5.20.0, we will
+"officially" end support for Perl 5.16.x, other than providing security
updates as described below.
=item *
years and decades, but not at the expense of our user community.
Existing syntax and semantics should only be marked for destruction in
-very limited circumstances. If a given language feature's continued
-inclusion in the language will cause significant harm to the language
-or prevent us from making needed changes to the runtime, then it may
-be considered for deprecation.
-
-Any language change which breaks backward-compatibility should be able to
-be enabled or disabled lexically. Unless code at a given scope declares
-that it wants the new behavior, that new behavior should be disabled.
-Which backward-incompatible changes are controlled implicitly by a
-'use v5.x.y' is a decision which should be made by the pumpking in
-consultation with the community.
-
-When a backward-incompatible change can't be toggled lexically, the decision
-to change the language must be considered very, very carefully. If it's
-possible to move the old syntax or semantics out of the core language
-and into XS-land, that XS module should be enabled by default unless
-the user declares that they want a newer revision of Perl.
+very limited circumstances. If they are believed to be very rarely used,
+stand in the way of actual improvement to the Perl language or perl
+interpreter, and if affected code can be easily updated to continue
+working, they may be considered for removal. When in doubt, caution
+dictates that we will favor backward compatibility. When a feature is
+deprecated, a statement of reasoning describing the decision process
+will be posted, and a link to it will be provided in the relevant
+perldelta documents.
+
+Using a lexical pragma to enable or disable legacy behavior should be
+considered when appropriate, and in the absence of any pragma legacy
+behavior should be enabled. Which backward-incompatible changes are
+controlled implicitly by a 'use v5.x.y' is a decision which should be
+made by the pumpking in consultation with the community.
Historically, we've held ourselves to a far higher standard than
backward-compatibility -- bugward-compatibility. Any accident of
New syntax and semantics which don't break existing language constructs
and syntax have a much lower bar. They merely need to prove themselves
-to be useful, elegant, well designed and well tested.
+to be useful, elegant, well designed, and well tested. In most cases,
+these additions will be marked as I<experimental> for some time. See
+below for more on that.
=head2 Terminology
features, you should contact the perl5-porters mailinglist if you find
an experimental feature useful and want to help shape its future.
+Experimental features must be experimental in two stable releases before being
+marked non-experimental. Experimental features will only have their
+experimental status revoked when they no longer have any design-changing bugs
+open against them and when they have remained unchanged in behavior for the
+entire length of a development cycle. In other words, a feature present in
+v5.20.0 may be marked no longer experimental in v5.22.0 if and only if its
+behavior is unchanged throughout all of v5.21.
+
=item deprecated
If something in the Perl core is marked as B<deprecated>, we may remove it
-from the core in the next stable release series, though we may not. As of
+from the core in the future, though we might not. Generally, backward
+incompatible changes will have deprecation warnings for two release
+cycles before being removed, but may be removed after just one cycle if
+the risk seems quite low or the benefits quite high.
+
+As of
Perl 5.12, deprecated features and modules warn the user as they're used.
-If you use a deprecated feature and believe that its removal from the Perl
-core would be a mistake, please contact the perl5-porters mailinglist and
-plead your case. We don't deprecate things without a good reason, but
-sometimes there's a counterargument we haven't considered. Historically,
-we did not distinguish between "deprecated" and "discouraged" features.
+When a module is deprecated, it will also be made available on CPAN.
+Installing it from CPAN will silence deprecation warnings for that module.
+
+If you use a deprecated feature or module and believe that its removal from
+the Perl core would be a mistake, please contact the perl5-porters
+mailinglist and plead your case. We don't deprecate things without a good
+reason, but sometimes there's a counterargument we haven't considered.
+Historically, we did not distinguish between "deprecated" and "discouraged"
+features.
=item discouraged
From time to time, we may mark language constructs and features which we
consider to have been mistakes as B<discouraged>. Discouraged features
-aren't candidates for removal in the next major release series, but
+aren't currently candidates for removal, but
we may later deprecate them if they're found to stand in the way of a
significant improvement to the Perl core.
=item removed
-Once a feature, construct or module has been marked as deprecated for a
-stable release cycle, we may remove it from the Perl core. Unsurprisingly,
-we say we've B<removed> these things.
+Once a feature, construct or module has been marked as deprecated, we
+may remove it from the Perl core. Unsurprisingly,
+we say we've B<removed> these things. When a module is removed, it will
+no longer ship with Perl, but will continue to be available on CPAN.
=back
=head1 MAINTENANCE BRANCHES
+New releases of maintenance branches should only contain changes that fall into
+one of the "acceptable" categories set out below, but must not contain any
+changes that fall into one of the "unacceptable" categories. (For example, a
+fix for a crashing bug must not be included if it breaks binary compatibility.)
+
+It is not necessary to include every change meeting these criteria, and in
+general the focus should be on addressing security issues, crashing bugs,
+regressions and serious installation issues. The temptation to include a
+plethora of minor changes that don't affect the installation or execution of
+perl (e.g. spelling corrections in documentation) should be resisted in order
+to reduce the overall risk of overlooking something. The intention is to
+create maintenance releases which are both worthwhile and which users can have
+full confidence in the stability of. (A secondary concern is to avoid burning
+out the maint-pumpking or overwhelming other committers voting on changes to be
+included (see L</"Getting changes into a maint branch"> below).)
+
+The following types of change may be considered acceptable, as long as they do
+not also fall into any of the "unacceptable" categories set out below:
+
=over
=item *
-New releases of maint should contain as few changes as possible.
-If there is any question about whether a given patch might merit
-inclusion in a maint release, then it almost certainly should not
-be included.
+Patches that fix CVEs or security issues. These changes should
+be run through the perl5-security-report@perl.org mailing list
+rather than applied directly.
=item *
-Portability fixes, such as changes to Configure and the files in
-hints/ are acceptable. Ports of Perl to a new platform, architecture
-or OS release that involve changes to the implementation are NOT
-acceptable.
+Patches that fix crashing bugs, assertion failures and
+memory corruption but which do not otherwise change perl's
+functionality or negatively impact performance.
=item *
-Documentation updates that correct factual errors, explain significant
-bugs or deficiences in the current implementation or fix broken markup
-are acceptable.
+Patches that fix regressions in perl's behavior relative to previous
+releases, no matter how old the regression, since some people may
+upgrade from very old versions of perl to the latest version.
=item *
-Patches that add new warnings or errors or deprecate features
-are not acceptable.
+Patches that fix anything which prevents or seriously impacts the build
+or installation of perl.
=item *
-Patches that fix crashing bugs that do not otherwise change Perl's
-functionality or negatively impact performance are acceptable.
+Portability fixes, such as changes to Configure and the files in
+the hints/ folder.
=item *
-Patches that fix CVEs or security issues are acceptable, but should
-be run through the perl5-security-report@perl.org mailing list
-rather than applied directly.
+Minimal patches that fix platform-specific test failures.
+
+=item *
+
+Documentation updates that correct factual errors, explain significant
+bugs or deficiencies in the current implementation, or fix broken markup.
=item *
-Updates to dual-life modules should consist of minimal patches to
-fix crashing or security issues (as above).
+Updates to dual-life modules should consist of minimal patches to
+fix crashing bugs or security issues (as above). Any changes made to
+dual-life modules for which CPAN is canonical should be coordinated with
+the upstream author.
+
+=back
+
+The following types of change are NOT acceptable:
+
+=over
=item *
-Minimal patches that fix platform-specific test failures or
-installation issues are acceptable. When these changes are made
-to dual-life modules for which CPAN is canonical, any changes
-should be coordinated with the upstream author.
+Patches that break binary compatibility. (Please talk to a pumpking.)
=item *
-New versions of dual-life modules should NOT be imported into maint.
-Those belong in the next stable series.
+Patches that add or remove features.
+
+=item *
+
+Patches that add new warnings or errors or deprecate features.
=item *
-Patches that add or remove features are not acceptable.
+Ports of Perl to a new platform, architecture or OS release that
+involve changes to the implementation.
=item *
-Patches that break binary compatibility are not acceptable. (Please
-talk to a pumpking.)
+New versions of dual-life modules should NOT be imported into maint.
+Those belong in the next stable series.
=back
+If there is any question about whether a given patch might merit
+inclusion in a maint release, then it almost certainly should not
+be included.
=head2 Getting changes into a maint branch
Historically, only the pumpking cherry-picked changes from bleadperl
-into maintperl. This has...scaling problems. At the same time,
+into maintperl. This has scaling problems. At the same time,
maintenance branches of stable versions of Perl need to be treated with
-great care. To that end, we're going to try out a new process for
-maint-5.12.
+great care. To that end, as of Perl 5.12, we have a new process for
+maint branches.
-Any committer may cherry-pick any commit from blead to maint-5.12 if
+Any committer may cherry-pick any commit from blead to a maint branch if
they send mail to perl5-porters announcing their intent to cherry-pick
-a specific commit along with a rationale for doing so and at least two
+a specific commit along with a rationale for doing so and at least two
other committers respond to the list giving their assent. (This policy
applies to current and former pumpkings, as well as other committers.)
+Other voting mechanisms may be used instead, as long as the same number of
+votes is gathered in a transparent manner. Specifically, proposals of
+which changes to cherry-pick must be visible to everyone on perl5-porters
+so that the views of everyone interested may be heard.
+
=head1 CONTRIBUTED MODULES
but, with very few exceptions, documentation isn't "dual-life" --
it doesn't need to fully describe how all old versions used to work.
+=head1 STANDARDS OF CONDUCT
+
+The official forum for the development of perl is the perl5-porters mailing
+list, mentioned above, and its bugtracker at rt.perl.org. All participants in
+discussion there are expected to adhere to a standard of conduct.
+
+=over 4
+
+=item *
+
+Always be civil.
+
+=item *
+
+Heed the moderators.
+
+=back
+
+Civility is simple: stick to the facts while avoiding demeaning remarks and
+sarcasm. It is not enough to be factual. You must also be civil. Responding
+in kind to incivility is not acceptable.
+
+If the list moderators tell you that you are not being civil, carefully
+consider how your words have appeared before responding in any way. You may
+protest, but repeated protest in the face of a repeatedly reaffirmed decision
+is not acceptable.
+
+Unacceptable behavior will result in a public and clearly identified warning.
+Repeated unacceptable behavior will result in removal from the mailing list and
+revocation of rights to update rt.perl.org. The first removal is for one
+month. Subsequent removals will double in length. After six months with no
+warning, a user's ban length is reset. Removals, like warnings, are public.
+
+The list of moderators will be public knowledge. At present, it is:
+Aaron Crane, Andy Dougherty, Ricardo Signes, Steffen Müller.
=head1 CREDITS
https://perl5.git.perl.org / perl5.git / blobdiff