How to Prevent Perl 5.12

I want software development to be so predictable that it's boring. I want people to take release dates for granted. I want them to yawn at completed deprecations. I want all of the surprises in new versions of Perl and Parrot to be delight at improvements: code runs faster, new features make your projects simpler and more elegant, rough edges keep disappearing. I want the development process to become repeated cycles of ideas, design, implementation, testing, refinement, and release. I want this cycle to happen annually, if not quarterly.

I want steady, sustainable progress in small, achievable, repeatable, and verifiable steps. I believe that's the only way to save Perl and its ecosystem from slow decline and irrelevance.

That's why I write here. This is a manifesto. My transparent intent is to identify obstacles and convince the rest of the Perl community to work around them (or better yet, to remove them). Some of those obstacles are the way we teach Perl. Some of those obstacles are the way we write and distribute Perl. Some of the most persistent and pernicious obstacles are the way we develop Perl itself:

• No one can predict when (or if) Perl 5.12 will come out.
• No one can predict which features it will have. (You can predict that it will have at least some of the new code currently in bleadperl which will not go into Perl 5.10, but can anyone tell me what those are?)
• No one can predict how many point releases there will be in the Perl 5.12 series (nor the Perl 5.10 series, for that matter).
• No one can predict how long people will support Perl 5.12, or Perl 5.10 for that matter.

I've written about the DarkPAN dependency management and support problem before. It's unrealistic to expect volunteers to maintain code they can't see, if that code even exists. That's unrealistic. p5p's attempts to do so are unsustainable; there's no feedback. There are only two motivations: the desire to write high quality software, and the desire to avoid guilt and shame. (That's false guilt, by the way.)

While thinking about a documented support policy for Perl 5, I came across a comment from Adam Kennedy:

I see the appropriate (and achievable) Long Term Support period for Perl as being around 8-10 years.

There are many possible descriptions of this expectation. The most polite I can imagine is "unsustainable". The easiest argument against it is one of the most persuasive.

Ten years ago, the newest Perl release was 5.005_03. Lexical filehandles, three-arg open, and the warnings pragma did not exist. Unicode was unreliable.

There have been fifteen stable releases of Perl in the intervening decade, even with the unpredictable release schedule. Biannual releases would have produced twenty stable releases of Perl. Quarterly releases -- my preference -- would have produced forty stable releases of Perl.

I won't speak for anyone else, but you couldn't pay me enough to support forty versions of a piece of software released over a decade. Good luck convincing a sizable fraction of the other 930 or so people listed in the Perl AUTHORS file to do the same.

The proper approach is to:

• Document a sustainable support and development policy, then follow it.
• Establish a regular release schedule.
• Extract all essential DarkPAN features worth supporting into tests for the core test suite.
• Replace the feature pragma with a pragma which explicitly limits the running instance to those features present in a specific release.
• (After fixing feature...) Change the default behavior of Perl 5 to enable modern features.
• Encourages businesses which believe they really must use ancient versions of Perl long past their shelf lives to purchase support contracts from businesses willing to take on that burden.

Continuing to pile this support burden on volunteers who do not know if the DarkPAN exists, let alone suffers from changes in modern Perls, is a great way to ensure that Perl 5.12 will never come out.

Put more positively, my suggestions are ways to reduce the barriers to participation for people who have an investment in the present and future of Perl 5. That's the only way to make Perl and its ecosystem sustainable: to divide the work among everyone who wants or needs it to succeed.