The Perl 5 release process

LWN recently published an article, "The unstoppable Perl release train?", that raised some questions about the Perl 5 release process. In particular, the article questioned how the Perl 5 Porters handled a recent bug report from Tom Christiansen about Unicode support. This article aims to provide the reader with a better understanding of the current Perl release process, how it benefits Perl 5 users, and how it has helped invigorate Perl 5 development.

First, a disclaimer. I am decidedly pro-Perl. I am paid to program in Perl, and I've been doing so for over ten years now. I've contributed to the Perl core, mostly in the form of documentation, and I was also the release manager for the December 2011 development release of Perl, Perl 5.15.6.

Who are the Perl 5 Porters?

I'll be mentioning this group regularly throughout the article, so you should know who they are. The Perl 5 Porters are the volunteers who develop and maintain the Perl 5 language. They consist of anyone who cares enough about Perl 5 to participate in discussions on the perl5-porters email list. There's no formal membership, and influence is based on a combination of hacking skill and the ability to not be a jerk. The more you contribute and the more you communicate, the more control you have over the future of Perl 5. This should sound familiar if you know how other FOSS projects work.

While there are many people on the list, there are not that many people who actively contribute to the Perl core's C code. Currently, there are two paid developers, Nicholas Clark and Dave Mitchell, who are funded by grants from the Perl Foundation. In addition, there are usually another two to six people actively hacking on the C core at any time. Many more people contribute in the form of small patches, documentation, tests, and updates to core Perl modules.

Perl 5 and Perl 6

There's a reason this article's title specifically says Perl 5. Larry launched the Perl 6 project over ten years ago. When it was first being discussed, many Perl users thought that Perl 6 would supplant Perl 5 in much the same way that Perl 5 supplanted Perl 4.

Since then, that expectation has changed. Perl 5 and Perl 6 are both being actively developed, and there's no expectation that Perl 6 will replace Perl 5 any time soon. We now say that both Perl 5 and Perl 6 are part of the Perl language family.

The two languages co-exist peacefully, and ideas cross-pollinate between the two communities regularly.

A brief history of Perl 5

Larry Wall released Perl 1 in December 1987. He released Perl 5.000 in October 1994. Perl 5 is the Perl most of us know and love (or hate) today. It introduced features like object-orientation, the ability to dynamically load extensions written in C (using the "XS" mechanism), modules, closures, and more.

After the Perl 5.000 release, other Porters started making releases of Perl. Larry was no longer the sole keeper of Perl, and Perl development adopted the notion of a "Pumpking". Initially, the Pumpking (there has not been a Pumpqueen yet, unfortunately) was the person responsible for shepherding the development of each stable release. However, Larry was still Benevolent Dictator for Life, and Perl development still followed Rules 1 and 2, which can be paraphrased as "Larry has the final say on Perl, and can contradict himself whenever he feels like it."

As Larry started spending more time on Perl 6 development, he became less involved with Perl 5. These days, his focus is almost exclusively on Perl 6. While Rules 1 and 2 still apply in theory, in practice Larry does not make decisions involving Perl 5. Instead, the Pumpking is in charge of the language. The first Pumpking to take on this responsibility was Jesse Vincent. Recently, Ricardo Signes took over the Pumpking position.

For a long time Perl's release schedule was "release it when it's done". There was no specific list of features for a given release, and it wasn't always clear what should block a release from going out. In some cases, major releases ended up coalescing around a big feature, like threads (5.6.0) or Unicode (5.6.0 and 5.8.0), and that drove the release. In other cases, releases were repeatedly delayed due to a vicious cycle of adding a feature, fixing its bugs, and then adding a new feature during the bug fixing stage.

The development process also failed to clearly distinguish between major and minor releases. There was a nearly two year gap between the release of 5.10.0 and 5.10.1. In hindsight, the 5.10.1 release was not a minor release, and deserved to be called 5.12.0.

The current release process and support schedule

After the long gap between 5.10.0 and 5.10.1, many Porters wanted to streamline the development process. When Jesse Vincent took over as Pumpking for Perl 5.12.0, the Porters adopted a "timeboxed" release schedule. The theory is that in April of each year, the Pumpking will package up the code in the "blead" branch (Perl's name for "master") and ship it as the new major stable release.

Each major release is followed by a series of minor releases. Minor releases are minor! They include a small number of changes that are focused on fixing the most critical bugs. New features or incompatibilities are never introduced in a minor release.

Each major release series is supported for two years, except for critical security fixes, which are supported for three years. David Golden has a great write up of this support policy on his blog.

All release numbers start with "5.". The second number represents the major version number. The last number is the minor release number. Even major version numbers indicate stable releases. Odd major versions indicate development releases (e.g. 5.11.x). Minor development releases are made each month for community review and testing.

Minor stable releases are always backward compatible with other minor releases in the same stable series, down to binary compatibility for XS (C-based) extensions. Major releases may break backward compatibility, but Perl 5 is conservative, and backward incompatibilities are not introduced lightly.

The first release to follow this schedule was Perl 5.12.0, released on April 12, 2010.

Aiming for stability

The release schedule includes three well-defined freeze points. The first is the "contentious" code freeze, which happens in December before the stable release. This means that any changes that don't have widespread agreement from the Porters at this time must wait until after the stable release to be merged. The next freeze point is for user-visible changes, such as API changes, new features, backward incompatibilities, etc. This freeze occurs in February. In March, a "full" code freeze goes into effect in order to finalize the April Release Candidate and subsequent stable release.

There's a lot of work that goes into making this possible. While the number of people with commit bits has expanded, there is much stronger pressure to do work in per-feature or per-bugfix branches. This lets blead stay stable enough for releases to actually happen on schedule.

The Perl release train is only somewhat unstoppable. It stops for release blocking issues. Deciding whether an issue should block a release is more of an art than a science. Some questions that can help determine whether an issue is a blocker are:

• Is the issue a regression as compared to the last stable release of Perl?
• Does the issue represent an unintentional break in backward compatibility?
• Does the issue break a huge number of CPAN modules, or a few really important ones?
• Does the issue cause a major performance problem with commonly occurring code?
• Does the issue break the ability to install modules from CPAN, or the ability to install Perl itself?
• Is someone willing to commit to fixing this before the scheduled release?

The exact decision as to whether an issue is a blocker is made by the Pumpking in consultation with the Porters. Typically, a few months before the stable release, the Pumpking will ask the Porters to trawl through the Perl 5 issue tracker and nominate issues for blocker status. After discussion on the mailing list, the Pumpking comes up with a "final" list of issues. This list isn't really final. If someone found a major regression the day before the release, that could be declared a blocker.

So why weren't the bugs that Tom Christiansen found declared to be release blockers? This is answered by the first question above. These bugs exist in the current stable release of Perl. They are not regressions. Releasing Perl 5.16.0 with these bugs does not make Perl's Unicode support any worse than it already is. However, delaying Perl 5.16.0 does mean that users would not have access to many other useful bug fixes and features.

Timeboxed releases ensure that users can expect improvements and bug fixes on a predictable schedule, without the long gaps that were common in Perl's earlier history.

As for the security bug discussed in the same thread, a fix is being worked on. It's possible that the fix will be ready for the 5.16.0 release. If it's not ready in time for 5.16.0 then there will be a 5.16.1 release when the fix is ready, as well as 5.14.3 and 5.12.5 releases.

Perl 5 has come a long way in the last few years. Every month, a new development release comes out, shepherded by a different release manager. Once a year, a new major version is released. Releasing a new major version is no longer a months-long ordeal. When the new release schedule was first proposed, many of us wondered if such an ambitious plan could work. Now, it almost seems routine.