This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
[perl #121771] Revert the new warning for ++ on non- /\A[a-zA-Z]+[0-9]*\z/
[perl5.git] / pod / perlpolicy.pod
index 2341414..8120cd8 100644 (file)
@@ -8,6 +8,57 @@ This document is the master document which records all written
 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
@@ -31,9 +82,9 @@ the Perl community should expect from Perl's developers:
 
 =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.12.x
+and earlier are now out of support.  As of the release of 5.18.0, we will
+"officially" end support for Perl 5.14.x, other than providing security
 updates as described below.
 
 =item *
@@ -154,27 +205,37 @@ an experimental feature useful and want to help shape its future.
 =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
 
@@ -220,6 +281,11 @@ rather than applied directly.
 
 =item *
 
+Patches that fix regressions in perl's behavior relative to previous
+releases are acceptable.
+
+=item *
+
 Updates to dual-life modules should consist of minimal patches to 
 fix crashing or security issues (as above).
 
@@ -250,12 +316,12 @@ talk to a pumpking.)
 =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 
 other committers respond to the list giving their assent. (This policy