This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
perldelta for 0cd52e23ae64
[perl5.git] / pod / perlpolicy.pod
index 6ee4b1e..063dae5 100644 (file)
@@ -84,9 +84,9 @@ the Perl community should expect from Perl's developers:
 
 =item *
 
-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
+We "officially" support the two most recent stable release series.  5.16.x
+and earlier are now out of support.  As of the release of 5.22.0, we will
+"officially" end support for Perl 5.18.x, other than providing security
 updates as described below.
 
 =item *
@@ -250,10 +250,21 @@ no longer ship with Perl, but will continue to be available on CPAN.
 
 =head1 MAINTENANCE BRANCHES
 
-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.
+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:
@@ -280,6 +291,11 @@ upgrade from very old versions of perl to the latest version.
 
 =item *
 
+Patches that fix bugs in features that were new in the corresponding 5.x.0
+stable release.
+
+=item *
+
 Patches that fix anything which prevents or seriously impacts the build
 or installation of perl.
 
@@ -334,6 +350,10 @@ 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
@@ -348,6 +368,17 @@ 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.
+
+It is not necessary for voting to be held on cherry-picking perldelta
+entries associated with changes that have already been cherry-picked, nor
+for the maint-pumpking to obtain votes on changes required by the
+F<Porting/release_managers_guide.pod> where such changes can be applied by
+the means of cherry-picking from blead.
+
 =head1 CONTRIBUTED MODULES
 
 
@@ -525,10 +556,14 @@ 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.
 
+While civility is required, kindness is encouraged; if you have any doubt about
+whether you are being civil, simply ask yourself, "Am I being kind?" and aspire
+to that.
+
 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.
+consider how your words have appeared before responding in any way.  Were they
+kind?  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