| 1 | =head1 NAME |
| 2 | |
| 3 | perlpolicy - Various and sundry policies and commitments related to the Perl core |
| 4 | |
| 5 | =head1 DESCRIPTION |
| 6 | |
| 7 | This document is the master document which records all written |
| 8 | policies about how the Perl 5 Porters collectively develop and maintain |
| 9 | the Perl core. |
| 10 | |
| 11 | =head1 MAINTENANCE AND SUPPORT |
| 12 | |
| 13 | Perl 5 is developed by a community, not a corporate entity. Every change |
| 14 | contributed to the Perl core is the result of a donation. Typically, these |
| 15 | donations are contributions of code or time by individual members of our |
| 16 | community. On occasion, these donations come in the form of corporate |
| 17 | or organizational sponsorship of a particular individual or project. |
| 18 | |
| 19 | As a volunteer organization, the commitments we make are heavily dependent |
| 20 | on the goodwill and hard work of individuals who have no obligation to |
| 21 | contribute to Perl. |
| 22 | |
| 23 | That being said, we value Perl's stability and security and have long |
| 24 | had an unwritten covenant with the broader Perl community to support |
| 25 | and maintain releases of Perl. |
| 26 | |
| 27 | This document codifies the support and maintenance commitments that |
| 28 | the Perl community should expect from Perl's developers: |
| 29 | |
| 30 | =over |
| 31 | |
| 32 | =item * |
| 33 | |
| 34 | We "officially" support the two most recent stable release |
| 35 | series'. As of the release of 5.14.0, we will "officially" |
| 36 | end support for Perl 5.10, other than providing security |
| 37 | updates as described below. |
| 38 | |
| 39 | =item * |
| 40 | |
| 41 | To the best of our ability, we will attempt to fix critical issues |
| 42 | in the two most recent stable 5.x release series'. Fixes for the |
| 43 | current release series take precedence over fixes for the previous |
| 44 | release series. |
| 45 | |
| 46 | =item * |
| 47 | |
| 48 | To the best of our ability, we will provide "critical" security patches |
| 49 | / releases for any major version of Perl initially released within the |
| 50 | past three years. We can only commit to providing these for the most |
| 51 | recent .y release in any 5.x.y series. |
| 52 | |
| 53 | =item * |
| 54 | |
| 55 | We will not provide security updates or bug fixes for development |
| 56 | releases of Perl. |
| 57 | |
| 58 | =item * |
| 59 | |
| 60 | We encourage vendors to ship the most recent supported release of |
| 61 | Perl at the time of their code freeze. |
| 62 | |
| 63 | =item * |
| 64 | |
| 65 | As a vendor, you may have a requirement to backport security fixes |
| 66 | beyond our 3 year support commitment. We can provide limited support and |
| 67 | advice to you as you do so and, where possible will try to apply |
| 68 | those patches to the relevant -maint branches in git, though we may or |
| 69 | may not choose to make numbered releases or "official" patches |
| 70 | available. Contact us at E<lt>perl5-security-report@perl.orgE<gt> |
| 71 | to begin that process. |
| 72 | |
| 73 | =back |
| 74 | |
| 75 | =head1 BACKWARD COMPATIBILITY AND DEPRECATION |
| 76 | |
| 77 | Our community has a long-held belief that backward-compatibility is a |
| 78 | virtue, even when the functionality in question is a design flaw. |
| 79 | |
| 80 | We would all love to unmake some mistakes we've made over the past |
| 81 | decades. Living with every design error we've ever made can lead |
| 82 | to painful stagnation. Unwinding our mistakes is very, very |
| 83 | difficult. Doing so without actively harming our users is |
| 84 | nearly impossible. |
| 85 | |
| 86 | Lately, ignoring or actively opposing compatibility with earlier versions |
| 87 | of Perl has come into vogue. Sometimes, a change is proposed which |
| 88 | wants to usurp syntax which previously had another meaning. Sometimes, |
| 89 | a change wants to improve previously-crazy semantics. |
| 90 | |
| 91 | Down this road lies madness. |
| 92 | |
| 93 | Requiring end-user programmers to change just a few language constructs, |
| 94 | even language constructs which no well-educated developer would ever |
| 95 | intentionally use is tantamount to saying "you should not upgrade to |
| 96 | a new release of Perl unless you have 100% test coverage and can do a |
| 97 | full manual audit of your codebase." If we were to have tools capable of |
| 98 | reliably upgrading Perl source code from one version of Perl to another, |
| 99 | this concern could be significantly mitigated. |
| 100 | |
| 101 | We want to ensure that Perl continues to grow and flourish in the coming |
| 102 | years and decades, but not at the expense of our user community. |
| 103 | |
| 104 | Existing syntax and semantics should only be marked for destruction in |
| 105 | very limited circumstances. If a given language feature's continued |
| 106 | inclusion in the language will cause significant harm to the language |
| 107 | or prevent us from making needed changes to the runtime, then it may |
| 108 | be considered for deprecation. |
| 109 | |
| 110 | Any language change which breaks backward-compatibility should be able to |
| 111 | be enabled or disabled lexically. Unless code at a given scope declares |
| 112 | that it wants the new behavior, that new behavior should be disabled. |
| 113 | Which backward-incompatible changes are controlled implicitly by a |
| 114 | 'use v5.x.y' is a decision which should be made by the pumpking in |
| 115 | consultation with the community. |
| 116 | |
| 117 | When a backward-incompatible change can't be toggled lexically, the decision |
| 118 | to change the language must be considered very, very carefully. If it's |
| 119 | possible to move the old syntax or semantics out of the core language |
| 120 | and into XS-land, that XS module should be enabled by default unless |
| 121 | the user declares that they want a newer revision of Perl. |
| 122 | |
| 123 | Historically, we've held ourselves to a far higher standard than |
| 124 | backward-compatibility -- bugward-compatibility. Any accident of |
| 125 | implementation or unintentional side-effect of running some bit of code |
| 126 | has been considered to be a feature of the language to be defended with |
| 127 | the same zeal as any other feature or functionality. No matter how |
| 128 | frustrating these unintentional features may be to us as we continue |
| 129 | to improve Perl, these unintentional features often deserve our |
| 130 | protection. It is very important that existing software written in |
| 131 | Perl continue to work correctly. If end-user developers have adopted a |
| 132 | bug as a feature, we need to treat it as such. |
| 133 | |
| 134 | New syntax and semantics which don't break existing language constructs |
| 135 | and syntax have a much lower bar. They merely need to prove themselves |
| 136 | to be useful, elegant, well designed and well tested. |
| 137 | |
| 138 | =head2 Terminology |
| 139 | |
| 140 | To make sure we're talking about the same thing when we discuss the removal |
| 141 | of features or functionality from the Perl core, we have specific definitions |
| 142 | for a few words and phrases. |
| 143 | |
| 144 | =over |
| 145 | |
| 146 | =item experimental |
| 147 | |
| 148 | If something in the Perl core is marked as B<experimental>, we may change |
| 149 | its behaviour, deprecate or remove it without notice. While we'll always |
| 150 | do our best to smooth the transition path for users of experimental |
| 151 | features, you should contact the perl5-porters mailinglist if you find |
| 152 | an experimental feature useful and want to help shape its future. |
| 153 | |
| 154 | =item deprecated |
| 155 | |
| 156 | If something in the Perl core is marked as B<deprecated>, we may remove it |
| 157 | from the core in the next stable release series, though we may not. As of |
| 158 | Perl 5.12, deprecated features and modules warn the user as they're used. |
| 159 | If you use a deprecated feature and believe that its removal from the Perl |
| 160 | core would be a mistake, please contact the perl5-porters mailinglist and |
| 161 | plead your case. We don't deprecate things without a good reason, but |
| 162 | sometimes there's a counterargument we haven't considered. Historically, |
| 163 | we did not distinguish between "deprecated" and "discouraged" features. |
| 164 | |
| 165 | =item discouraged |
| 166 | |
| 167 | From time to time, we may mark language constructs and features which we |
| 168 | consider to have been mistakes as B<discouraged>. Discouraged features |
| 169 | aren't candidates for removal in the next major release series, but |
| 170 | we may later deprecate them if they're found to stand in the way of a |
| 171 | significant improvement to the Perl core. |
| 172 | |
| 173 | =item removed |
| 174 | |
| 175 | Once a feature, construct or module has been marked as deprecated for a |
| 176 | stable release cycle, we may remove it from the Perl core. Unsurprisingly, |
| 177 | we say we've B<removed> these things. |
| 178 | |
| 179 | =back |
| 180 | |
| 181 | =head1 MAINTENANCE BRANCHES |
| 182 | |
| 183 | =over |
| 184 | |
| 185 | =item * |
| 186 | |
| 187 | New releases of maint should contain as few changes as possible. |
| 188 | If there is any question about whether a given patch might merit |
| 189 | inclusion in a maint release, then it almost certainly should not |
| 190 | be included. |
| 191 | |
| 192 | =item * |
| 193 | |
| 194 | Portability fixes, such as changes to Configure and the files in |
| 195 | hints/ are acceptable. Ports of Perl to a new platform, architecture |
| 196 | or OS release that involve changes to the implementation are NOT |
| 197 | acceptable. |
| 198 | |
| 199 | =item * |
| 200 | |
| 201 | Documentation updates that correct factual errors, explain significant |
| 202 | bugs or deficiences in the current implementation or fix broken markup |
| 203 | are acceptable. |
| 204 | |
| 205 | =item * |
| 206 | |
| 207 | Patches that add new warnings or errors or deprecate features |
| 208 | are not acceptable. |
| 209 | |
| 210 | =item * |
| 211 | |
| 212 | Patches that fix crashing bugs that do not otherwise change Perl's |
| 213 | functionality or negatively impact performance are acceptable. |
| 214 | |
| 215 | =item * |
| 216 | |
| 217 | Patches that fix CVEs or security issues are acceptable, but should |
| 218 | be run through the perl5-security-report@perl.org mailing list |
| 219 | rather than applied directly. |
| 220 | |
| 221 | =item * |
| 222 | |
| 223 | Updates to dual-life modules should consist of minimal patches to |
| 224 | fix crashing or security issues (as above). |
| 225 | |
| 226 | =item * |
| 227 | |
| 228 | Minimal patches that fix platform-specific test failures or |
| 229 | installation issues are acceptable. When these changes are made |
| 230 | to dual-life modules for which CPAN is canonical, any changes |
| 231 | should be coordinated with the upstream author. |
| 232 | |
| 233 | =item * |
| 234 | |
| 235 | New versions of dual-life modules should NOT be imported into maint. |
| 236 | Those belong in the next stable series. |
| 237 | |
| 238 | =item * |
| 239 | |
| 240 | Patches that add or remove features are not acceptable. |
| 241 | |
| 242 | =item * |
| 243 | |
| 244 | Patches that break binary compatibility are not acceptable. (Please |
| 245 | talk to a pumpking.) |
| 246 | |
| 247 | =back |
| 248 | |
| 249 | |
| 250 | =head2 Getting changes into a maint branch |
| 251 | |
| 252 | Historically, only the pumpking cherry-picked changes from bleadperl |
| 253 | into maintperl. This has...scaling problems. At the same time, |
| 254 | maintenance branches of stable versions of Perl need to be treated with |
| 255 | great care. To that end, we're going to try out a new process for |
| 256 | maint-5.12. |
| 257 | |
| 258 | Any committer may cherry-pick any commit from blead to maint-5.12 if |
| 259 | they send mail to perl5-porters announcing their intent to cherry-pick |
| 260 | a specific commit along with a rationale for doing so and at least two |
| 261 | other committers respond to the list giving their assent. (This policy |
| 262 | applies to current and former pumpkings, as well as other committers.) |
| 263 | |
| 264 | =head1 CONTRIBUTED MODULES |
| 265 | |
| 266 | |
| 267 | =head2 A Social Contract about Artistic Control |
| 268 | |
| 269 | What follows is a statement about artistic control, defined as the ability |
| 270 | of authors of packages to guide the future of their code and maintain |
| 271 | control over their work. It is a recognition that authors should have |
| 272 | control over their work, and that it is a responsibility of the rest of |
| 273 | the Perl community to ensure that they retain this control. It is an |
| 274 | attempt to document the standards to which we, as Perl developers, intend |
| 275 | to hold ourselves. It is an attempt to write down rough guidelines about |
| 276 | the respect we owe each other as Perl developers. |
| 277 | |
| 278 | This statement is not a legal contract. This statement is not a legal |
| 279 | document in any way, shape, or form. Perl is distributed under the GNU |
| 280 | Public License and under the Artistic License; those are the precise legal |
| 281 | terms. This statement isn't about the law or licenses. It's about |
| 282 | community, mutual respect, trust, and good-faith cooperation. |
| 283 | |
| 284 | We recognize that the Perl core, defined as the software distributed with |
| 285 | the heart of Perl itself, is a joint project on the part of all of us. |
| 286 | From time to time, a script, module, or set of modules (hereafter referred |
| 287 | to simply as a "module") will prove so widely useful and/or so integral to |
| 288 | the correct functioning of Perl itself that it should be distributed with |
| 289 | the Perl core. This should never be done without the author's explicit |
| 290 | consent, and a clear recognition on all parts that this means the module |
| 291 | is being distributed under the same terms as Perl itself. A module author |
| 292 | should realize that inclusion of a module into the Perl core will |
| 293 | necessarily mean some loss of control over it, since changes may |
| 294 | occasionally have to be made on short notice or for consistency with the |
| 295 | rest of Perl. |
| 296 | |
| 297 | Once a module has been included in the Perl core, however, everyone |
| 298 | involved in maintaining Perl should be aware that the module is still the |
| 299 | property of the original author unless the original author explicitly |
| 300 | gives up their ownership of it. In particular: |
| 301 | |
| 302 | =over |
| 303 | |
| 304 | =item * |
| 305 | |
| 306 | The version of the module in the Perl core should still be considered the |
| 307 | work of the original author. All patches, bug reports, and so |
| 308 | forth should be fed back to them. Their development directions |
| 309 | should be respected whenever possible. |
| 310 | |
| 311 | =item * |
| 312 | |
| 313 | Patches may be applied by the pumpkin holder without the explicit |
| 314 | cooperation of the module author if and only if they are very minor, |
| 315 | time-critical in some fashion (such as urgent security fixes), or if |
| 316 | the module author cannot be reached. Those patches must still be |
| 317 | given back to the author when possible, and if the author decides on |
| 318 | an alternate fix in their version, that fix should be strongly |
| 319 | preferred unless there is a serious problem with it. Any changes not |
| 320 | endorsed by the author should be marked as such, and the contributor |
| 321 | of the change acknowledged. |
| 322 | |
| 323 | =item * |
| 324 | |
| 325 | The version of the module distributed with Perl should, whenever |
| 326 | possible, be the latest version of the module as distributed by the |
| 327 | author (the latest non-beta version in the case of public Perl |
| 328 | releases), although the pumpkin holder may hold off on upgrading the |
| 329 | version of the module distributed with Perl to the latest version |
| 330 | until the latest version has had sufficient testing. |
| 331 | |
| 332 | =back |
| 333 | |
| 334 | In other words, the author of a module should be considered to have final |
| 335 | say on modifications to their module whenever possible (bearing in mind |
| 336 | that it's expected that everyone involved will work together and arrive at |
| 337 | reasonable compromises when there are disagreements). |
| 338 | |
| 339 | As a last resort, however: |
| 340 | |
| 341 | |
| 342 | If the author's vision of the future of their module is sufficiently |
| 343 | different from the vision of the pumpkin holder and perl5-porters as a |
| 344 | whole so as to cause serious problems for Perl, the pumpkin holder may |
| 345 | choose to formally fork the version of the module in the Perl core from the |
| 346 | one maintained by the author. This should not be done lightly and |
| 347 | should B<always> if at all possible be done only after direct input |
| 348 | from Larry. If this is done, it must then be made explicit in the |
| 349 | module as distributed with the Perl core that it is a forked version and |
| 350 | that while it is based on the original author's work, it is no longer |
| 351 | maintained by them. This must be noted in both the documentation and |
| 352 | in the comments in the source of the module. |
| 353 | |
| 354 | Again, this should be a last resort only. Ideally, this should never |
| 355 | happen, and every possible effort at cooperation and compromise should be |
| 356 | made before doing this. If it does prove necessary to fork a module for |
| 357 | the overall health of Perl, proper credit must be given to the original |
| 358 | author in perpetuity and the decision should be constantly re-evaluated to |
| 359 | see if a remerging of the two branches is possible down the road. |
| 360 | |
| 361 | In all dealings with contributed modules, everyone maintaining Perl should |
| 362 | keep in mind that the code belongs to the original author, that they may |
| 363 | not be on perl5-porters at any given time, and that a patch is not |
| 364 | official unless it has been integrated into the author's copy of the |
| 365 | module. To aid with this, and with points #1, #2, and #3 above, contact |
| 366 | information for the authors of all contributed modules should be kept with |
| 367 | the Perl distribution. |
| 368 | |
| 369 | Finally, the Perl community as a whole recognizes that respect for |
| 370 | ownership of code, respect for artistic control, proper credit, and active |
| 371 | effort to prevent unintentional code skew or communication gaps is vital |
| 372 | to the health of the community and Perl itself. Members of a community |
| 373 | should not normally have to resort to rules and laws to deal with each |
| 374 | other, and this document, although it contains rules so as to be clear, is |
| 375 | about an attitude and general approach. The first step in any dispute |
| 376 | should be open communication, respect for opposing views, and an attempt |
| 377 | at a compromise. In nearly every circumstance nothing more will be |
| 378 | necessary, and certainly no more drastic measure should be used until |
| 379 | every avenue of communication and discussion has failed. |
| 380 | |
| 381 | |
| 382 | =head1 DOCUMENTATION |
| 383 | |
| 384 | Perl's documentation is an important resource for our users. It's |
| 385 | incredibly important for Perl's documentation to be reasonably coherent |
| 386 | and to accurately reflect the current implementation. |
| 387 | |
| 388 | Just as P5P collectively maintains the codebase, we collectively |
| 389 | maintain the documentation. Writing a particular bit of documentation |
| 390 | doesn't give an author control of the future of that documentation. |
| 391 | At the same time, just as source code changes should match the style |
| 392 | of their surrounding blocks, so should documentation changes. |
| 393 | |
| 394 | Examples in documentation should be illustrative of the concept |
| 395 | they're explaining. Sometimes, the best way to show how a |
| 396 | language feature works is with a small program the reader can |
| 397 | run without modification. More often, examples will consist |
| 398 | of a snippet of code containing only the "important" bits. |
| 399 | The definition of "important" varies from snippet to snippet. |
| 400 | Sometimes it's important to declare C<use strict> and C<use warnings>, |
| 401 | initialize all variables and fully catch every error condition. |
| 402 | More often than not, though, those things obscure the lesson |
| 403 | the example was intended to teach. |
| 404 | |
| 405 | As Perl is developed by a global team of volunteers, our |
| 406 | documentation often contains spellings which look funny |
| 407 | to I<somebody>. Choice of American/British/Other spellings |
| 408 | is left as an exercise for the author of each bit of |
| 409 | documentation. When patching documentation, try to emulate |
| 410 | the documentation around you, rather than changing the existing |
| 411 | prose. |
| 412 | |
| 413 | In general, documentation should describe what Perl does "now" rather |
| 414 | than what it used to do. It's perfectly reasonable to include notes |
| 415 | in documentation about how behaviour has changed from previous releases, |
| 416 | but, with very few exceptions, documentation isn't "dual-life" -- |
| 417 | it doesn't need to fully describe how all old versions used to work. |
| 418 | |
| 419 | |
| 420 | =head1 CREDITS |
| 421 | |
| 422 | "Social Contract about Contributed Modules" originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters. |
| 423 | |