This is a live mirror of the Perl 5 development currently hosted at
maint policy: Reword/expand the ambiguous "as few changes as possible" phrase
authorSteve Hay <>
Thu, 26 Feb 2015 13:29:36 +0000 (13:29 +0000)
committerSteve Hay <>
Fri, 6 Mar 2015 08:15:59 +0000 (08:15 +0000)
This phrase caused much debate during the release of 5.20.2. A literal
interpretation of it would be just a version bump, which was clearly not
its intention. Debate ensued as to what was its real meaning, and the
consensus seemed to be that the list of "acceptable"/"unacceptable" types
of change was about right, but that not every eligible change should be
included. Not many committers are interested in reviewing a long list of
minor spelling corrections etc, causing a lack of interest in voting, and
an attendant risk of something important being missed amongst all the
"noise". The focus should mainly be on security / crash / regression /
installation issues, with the aim being to produce a worthwhile release
without needlessly increasing risk and/or burning people out. I hope the
new wording captures this.


index e93edf0..0364d5c 100644 (file)
@@ -250,7 +250,21 @@ no longer ship with Perl, but will continue to be available on CPAN.
-New releases of maint should contain as few changes as possible.
+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: