Dominic Hargreaves > perl-5.12.5 > release_managers_guide


Annotate this POD


Source   Latest Release: perl-5.19.11


release_managers_guide - Releasing a new version of perl 5.x

As of August 2009, this file is mostly complete, although it is missing some detail on doing a major release (e.g. 5.10.0 -> 5.12.0). Note that things change at each release, so there may be new things not covered here, or tools may need updating.


This document describes the series of tasks required - some automatic, some manual - to produce a perl release of some description, be that a snaphot, release candidate, or final, numbered release of maint or blead.

The release process has traditionally been executed by the current pumpking. Blead releases from 5.11.0 forward are made each month on the 20th by a non-pumpking release engineer. The release engineer roster and schedule can be found in Porting/release_schedule.pod.

This document both helps as a check-list for the release engineer and is a base for ideas on how the various tasks could be automated or distributed.

The outline of a typical release cycle is as follows:

    (5.10.1 is released, and post-release actions have been done)

    ...time passes...

    an occasional snapshot is released, that still identifies itself as

    ...time passes...

    a few weeks before the release, a number of steps are performed,
        including bumping the version to 5.10.2

    ...a few weeks passes...

    perl-5.10.2-RC1 is released

    perl-5.10.2 is released

    post-release actions are performed, including creating new

    ... the cycle continues ...


Some of the tasks described below apply to all four types of release of Perl. (snapshot, RC, final release of maint, final release of blead). Some of these tasks apply only to a subset of these release types. If a step does not apply to a given type of release, you will see a notation to that effect at the beginning of the step.

Release types


A snapshot is intended to encourage in-depth testing from time-to-time, for example after a key point in the stabilisation of a branch. It requires fewer steps than a full release, and the version number of perl in the tarball will usually be the same as that of the previous release.

Release Candidate (RC)

A release candidate is an attempt to produce a tarball that is a close as possible to the final release. Indeed, unless critical faults are found during the RC testing, the final release will be identical to the RC barring a few minor fixups (updating the release date in perlhist.pod, removing the RC status from patchlevel.h, etc). If faults are found, then the fixes should be put into a new release candidate, never directly into a final release.

Stable/Maint release

At this point you should have a working release candidate with few or no changes since.

It's essentially the same procedure as for making a release candidate, but with a whole bunch of extra post-release steps.

Blead release

It's essentially the same procedure as for making a release candidate, but with a whole bunch of extra post-release steps.


Before you can make an official release of perl, there are a few hoops you need to jump through:

PAUSE account

SKIP this step for SNAPSHOT

Make sure you have a PAUSE account suitable for uploading a perl release. If you don't have a PAUSE account, then request one:

Check that your account is allowed to upload perl distros: goto, login, then select 'upload file to CPAN'; there should be a "For pumpkings only: Send a CC" tickbox. If not, ask Andreas König to add your ID to the list of people allowed to upload something called perl. You can find Andreas' email address at:

Make sure that knows that you're allowed to upload perl distros. Contact Graham Barr to make sure that you're on the right list.

CPAN mirror

Some release engineering steps require a full mirror of the CPAN. Work to fall back to using a remote mirror via HTTP is incomplete but ongoing. (No, a minicpan mirror is not sufficient)

git checkout and commit bit

You will need a working git installation, checkout of the perl git repository and perl commit bit. For information about working with perl and git, see pod/perlrepository.pod.

If you are not yet a perl committer, you won't be able to make a release. Have a chat with whichever evil perl porter tried to talk you into the idea in the first place to figure out the best way to resolve the issue.

Quotation for release announcement epigraph

SKIP this step for SNAPSHOT and RC

For a numbered blead or maint release of perl, you will need a quotation to use as an epigraph to your release announcement. (There's no harm in having one for a snapshot, but it's not required).

Building a release - advance actions

The work of building a release candidate for a numbered release of perl generally starts several weeks before the first release candidate. Some of the following steps should be done regularly, but all must be done in the run up to a release.

Building a release - on the day

This section describes the actions required to make a release (or snapshot etc) that are performed on the actual day.


Based on, plus a whole bunch of other sources, including private correspondence.

syntax highlighting: