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