man pages section 1: User Commands

Exit Print View

Updated: July 2014

perlpolicy (1)


perlpolicy - Various and sundry policies and commitments related to the perl core


Please see following description for synopsis


Perl Programmers Reference Guide                    PERLPOLICY(1)

     perlpolicy - Various and sundry policies and commitments
     related to the perl core

     This document is the master document which records all
     written policies about how the Perl 5 Porters collectively
     develop and maintain the Perl core.

     Perl 5 is developed by a community, not a corporate entity.
     Every change contributed to the Perl core is the result of a
     donation. Typically, these donations are contributions of
     code or time by individual members of our community. On
     occasion, these donations come in the form of corporate or
     organizational sponsorship of a particular individual or

     As a volunteer organization, the commitments we make are
     heavily dependent on the goodwill and hard work of
     individuals who have no obligation to contribute to Perl.

     That being said, we value Perl's stabilty and security and
     have long had an unwritten covenant with the broader Perl
     community to support and maintain releases of Perl.

     This document codifies the support and maintenance
     commitments that the Perl community should expect from
     Perl's developers:

     o   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 updates as described below.

     o   To the best of our ability, we will attempt to fix
         critical issues in the two most recent stable 5.x
         release series'.  Fixes for the current release series
         take precedence over fixes for the previous release

     o   To the best of our ability, we will provide "critical"
         security patches / releases for any major version of
         Perl initially released within the past three years.  We
         can only commit to providing these for the most recent
         .y release in any 5.x.y series.

     o   We will not provide security updates or bug fixes for
         development releases of Perl.

     o   We encourage vendors to ship the most recent supported
         release of Perl at the time of their code freeze.

perl v5.12.5         Last change: 2012-11-03                    1

Perl Programmers Reference Guide                    PERLPOLICY(1)

     o   As a vendor, you may have a requirement to backport
         security fixes beyond our 3 year support commitment.  We
         can provide limited support and advice to you as you do
         so and, where possible will try to apply those patches
         to the relevant -maint branches in git, though we may or
         may not choose to make numbered releases or "official"
         patches available.  Contact us at
         <> to begin that process.

     Our community has a long-held belief that backward-
     compatibility is a virtue, even when the functionality in
     question is a design flaw.

     We would all love to unmake some mistakes we've made over
     the past decades.  Living with every design error we've ever
     made can lead to painful stagnation.  Unwinding our mistakes
     is very, very difficult.  Doing so without actively harming
     our users is nearly impossible.

     Lately, ignoring or actively opposing compatibility with
     earlier versions of Perl has come into vogue.  Sometimes, a
     change is proposed which wants to usurp syntax which
     previously had another meaning.  Sometimes, a change wants
     to improve previously-crazy semantics.

     Down this road lies madness.

     Requiring end-user programmers to change just a few language
     constructs, even language constructs which no well-educated
     developer would ever intentionally use is tantamount to
     saying "you should not upgrade to a new release of Perl
     unless you have 100% test coverage and can do a full manual
     audit of your codebase."  If we were to have tools capable
     of reliably upgrading Perl source code from one version of
     Perl to another, this concern could be significantly

     We want to ensure that Perl continues to grow and flourish
     in the coming 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

perl v5.12.5         Last change: 2012-11-03                    2

Perl Programmers Reference Guide                    PERLPOLICY(1)

     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

     Historically, we've held ourselves to a far higher standard
     than backward-compatibility -- bugward-compatibility.  Any
     accident of implementation or unintentional side-effect of
     running some bit of code has been considered to be a feature
     of the language to be defended with the same zeal as any
     other feature or functionality.  No matter how frustrating
     these unintentional features may be to us as we continue to
     improve Perl, these unintentional features often deserve our
     protection.  It is very important that existing software
     written in Perl continue to work correctly.  If end-user
     developers have adopted a bug as a feature, we need to treat
     it as such.

     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 make sure we're talking about the same thing when we
     discuss the removal of features or functionality from the
     Perl core, we have specific definitions for a few words and

         If something in the Perl core is marked as experimental,
         we may change its behaviour, deprecate or remove it
         without notice. While we'll always do our best to smooth
         the transition path for users of experimental features,
         you should contact the perl5-porters mailinglist if you
         find an experimental feature useful and want to help
         shape its future.

         If something in the Perl core is marked as deprecated,
         we may remove it from thecore in the next stable release
         series, though we may not. 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

perl v5.12.5         Last change: 2012-11-03                    3

Perl Programmers Reference Guide                    PERLPOLICY(1)

         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.

         From time to time, we may mark language constructs and
         features which we consider to have been mistakes as
         discouraged.  Discouraged features aren't candidates for
         removal in the next major release series, but we may
         later deprecate them if they're found to stand in the
         way of a significant improvement to the core.

         Once a feature, construct or module has been marked as
         deprecated for a stable release cycle, we may remove it
         from the core.  Unsurprisingly, we say we've removed
         these things.

     o   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.

     o   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.

     o   Documentation updates are acceptable.

     o   Patches that add new warnings or errors or deprecate
         features are not acceptable.

     o   Patches that fix crashing bugs that do not otherwise
         change Perl's functionality or negatively impact
         performance are acceptable.

     o   Patches that fix CVEs or security issues are acceptable,
         but should be run through the mailing list rather than
         applied directly.

     o   Updates to dual-life modules should consist of minimal
         patches to fix crashing or security issues (as above).

     o   New versions of dual-life modules should NOT be imported
         into maint.  Those belong in the next stable series.

perl v5.12.5         Last change: 2012-11-03                    4

Perl Programmers Reference Guide                    PERLPOLICY(1)

     o   Patches that add or remove features are not acceptable.

     o   Patches that break binary compatibility are not
         acceptable.  (Please talk to a pumpking.)

  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, 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.

     Any committer may cherry-pick any commit from blead to
     maint-5.12 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
     applies to current and former pumpkings, as well as other

  A Social Contract about Artistic Control
     What follows is a statement about artistic control, defined
     as the ability of authors of packages to guide the future of
     their code and maintain control over their work.  It is a
     recognition that authors should have control over their
     work, and that it is a responsibility of the rest of the
     Perl community to ensure that they retain this control.  It
     is an attempt to document the standards to which we, as Perl
     developers, intend to hold ourselves.  It is an attempt to
     write down rough guidelines about the respect we owe each
     other as Perl developers.

     This statement is not a legal contract.  This statement is
     not a legal document in any way, shape, or form.  Perl is
     distributed under the GNU Public License and under the
     Artistic License; those are the precise legal terms.  This
     statement isn't about the law or licenses.  It's about
     community, mutual respect, trust, and good-faith

     We recognize that the Perl core, defined as the software
     distributed with the heart of Perl itself, is a joint
     project on the part of all of us.  From time to time, a
     script, module, or set of modules (hereafter referred to
     simply as a "module") will prove so widely useful and/or so
     integral to the correct functioning of Perl itself that it
     should be distributed with Perl core.  This should never be
     done without the author's explicit consent, and a clear
     recognition on all parts that this means the module is being
     distributed under the same terms as Perl itself.  A module
     author should realize that inclusion of a module into the

perl v5.12.5         Last change: 2012-11-03                    5

Perl Programmers Reference Guide                    PERLPOLICY(1)

     Perl core will necessarily mean some loss of control over
     it, since changes may occasionally have to be made on short
     notice or for consistency with the rest of Perl.

     Once a module has been included in the Perl core, however,
     everyone involved in maintaining Perl should be aware that
     the module is still the property of the original author
     unless the original author explicitly gives up their
     ownership of it.  In particular:

     o   The version of the module in the core should still be
         considered the work of the original author.  All
         patches, bug reports, and so forth should be fed back to
         them.  Their development directions should be respected
         whenever possible.

     o   Patches may be applied by the pumpkin holder without the
         explicit cooperation of the module author if and only if
         they are very minor, time-critical in some fashion (such
         as urgent security fixes), or if the module author
         cannot be reached.  Those patches must still be given
         back to the author when possible, and if the author
         decides on an alternate fix in their version, that fix
         should be strongly preferred unless there is a serious
         problem with it.  Any changes not endorsed by the author
         should be marked as such, and the contributor of the
         change acknowledged.

     o   The version of the module distributed with Perl should,
         whenever possible, be the latest version of the module
         as distributed by the author (the latest non-beta
         version in the case of public Perl releases), although
         the pumpkin holder may hold off on upgrading the version
         of the module distributed with Perl to the latest
         version until the latest version has had sufficient

     In other words, the author of a module should be considered
     to have final say on modifications to their module whenever
     possible (bearing in mind that it's expected that everyone
     involved will work together and arrive at reasonable
     compromises when there are disagreements).

     As a last resort, however:

     If the author's vision of the future of their module is
     sufficiently different from the vision of the pumpkin holder
     and perl5-porters as a whole so as to cause serious problems
     for Perl, the pumpkin holder may choose to formally fork the
     version of the module in the core from the one maintained by
     the author.  This should not be done lightly and should
     always if at all possible be done only after direct input

perl v5.12.5         Last change: 2012-11-03                    6

Perl Programmers Reference Guide                    PERLPOLICY(1)

     from Larry.  If this is done, it must then be made explicit
     in the module as distributed with Perl core that it is a
     forked version and that while it is based on the original
     author's work, it is no longer maintained by them.  This
     must be noted in both the documentation and in the comments
     in the source of the module.

     Again, this should be a last resort only.  Ideally, this
     should never happen, and every possible effort at
     cooperation and compromise should be made before doing this.
     If it does prove necessary to fork a module for the overall
     health of Perl, proper credit must be given to the original
     author in perpetuity and the decision should be constantly
     re-evaluated to see if a remerging of the two branches is
     possible down the road.

     In all dealings with contributed modules, everyone
     maintaining Perl should keep in mind that the code belongs
     to the original author, that they may not be on
     perl5-porters at any given time, and that a patch is not
     official unless it has been integrated into the author's
     copy of the module.  To aid with this, and with points #1,
     #2, and #3 above, contact information for the authors of all
     contributed modules should be kept with the Perl

     Finally, the Perl community as a whole recognizes that
     respect for ownership of code, respect for artistic control,
     proper credit, and active effort to prevent unintentional
     code skew or communication gaps is vital to the health of
     the community and Perl itself.  Members of a community
     should not normally have to resort to rules and laws to deal
     with each other, and this document, although it contains
     rules so as to be clear, is about an attitude and general
     approach.  The first step in any dispute should be open
     communication, respect for opposing views, and an attempt at
     a compromise.  In nearly every circumstance nothing more
     will be necessary, and certainly no more drastic measure
     should be used until every avenue of communication and
     discussion has failed.

     Social Contract about Contributed Modules originally by Russ
     Allbery <> and the perl5-porters.

     See attributes(5) for descriptions of the following

perl v5.12.5         Last change: 2012-11-03                    7

Perl Programmers Reference Guide                    PERLPOLICY(1)

     |Availability   | runtime/perl-512 |
     |Stability      | Uncommitted      |
     This software was built from source available at  The original
     community source was downloaded from

     Further information about this software can be found on the
     open source community website at

perl v5.12.5         Last change: 2012-11-03                    8