Release Process

by Elizabeth Leddy — last modified Mar 26, 2012 05:51 AM

Plone uses a time-based release process, which helps to produce releases of predictable size and complexity. In order to make this work there are some requirements on how new features get accepted and implemented.

Special roles

There are some special roles in the Plone community of which the release manager and the framework team are the two important ones for the release process. For every major release series a release manager is elected by the Plone foundation board who has the authority to make certain final decisions for a release. The framework team is a group of people who assist the release manager in the process of reviewing any suggested features.

Release phases

The normal development cycle of a Plone release consists of various phases. See the Plone roadmap for semi-concrete dates for the next upcoming releases.

Discussion and Planning

People suggest new features and discuss them. We use a lightweight formal process which helps to foster and document this. See the below paragraph on enhancing Plone for the details.

Proposal freeze date

For each release there is a certain date by which all new feature proposals must have been submitted for review. After this date no features will be accepted anymore for this particular release.

Alpha releases

We will release various snapshots of the current release bundle that we package up to give out for testing. Migration to/from specific alphas is not supported.

Feature freeze date / Beta releases

By this date all features must have been completed and all code has to be integrated. Only non-invasive changes, user interface work and bug fixes are done now. Migrations supported to/from specific betas.

Release Candidate

Ideally, the last beta that was bug free. No changes to the code. Should not require any migration steps apart from the ones required in the betas. If any problems are found and fixed, a new release candidate is issued.

Final release / Expected release date

Normally the last release candidate that was issued without any show-stopper bugs.

Bug fix releases

No software is perfect. Once a sufficient large or critical number of bugs have been found for a certain release, the release manager releases a new bug fix release a.k.a. third-dot release (for example 2.1.2).

Enhancing Plone

If you have any idea on how to make Plone even better as it is today, you should first talk with other people about your ideas. Both the IRC channel and the developers mailing list are good starting points for this. Talking to people about it will give you some pointers about the feasibility of the feature, and give you a good starting point for further work.

If your change or improvement is a big one, then you'll be asked to write a PLIP - Plone Improvement Proposal. In the PLIP you'll explain exactly what it is you want to do, how to do it and how it will integrate. Full documentation of the PLIP process is available in the coredev documentation.