1.3. Release process

This documents tries to explain our release cycle and how we discuss and decide about feature additions.

General

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 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

Work out the idea

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. To add a PLIP, you need to be on the development team, so you can add it as an Improvement Proposal in the Plone Roadmap area.

When writing a PLIP, be as specific and to-the-point as you can. Remember your audience - to get support for your proposal, people will have to be able to read it! A good PLIP is sufficiently clear for a knowlegable Plone user to be able to understand the proposed changes, and sufficiently detailed for the release manager and other developers to understand the full impact the proposal would have on the codebase. You don't have to list every line of code that needs to be changed, but you should also give an indication that you have some idea that how the change can be feasibly implemented.

If your change is minor then a ticket in the tracker will be sufficient, added as an enhancement. The key point here is that each change needs documentation so other users can see what it is. This can be in the form of an issue tracker entry, or a PLIP in the case of a bigger change. A bug or minor change does normally not need to go through a review process - a PLIP does.

When you've done your PLIP and you're happy with it, announce it on the framework team mailing list . People will come and read the proposal and give feedback (hopefully positive).

At this point there is one key decision made by the developers:

  • your PLIP will be adopted into Plone
  • your PLIP will not be adopted

The latter isn't bad, it's just that this is not appropriate to be in the Plone core and have all the Plone team support. Each PLIP that gets accepted places a burden on the team, so people are selective in this process. There are many great products Plone uses that aren't directly part of Plone.

Start working on it

You can start the development at any time - but if you are going to modify Plone itself, you might want to wait to see if your idea is approved first to save yourself some work if it isn't. Your code has to be in an open accessible code versioning repository and you have to make a release bundle which allows the framework team to easily review your work. Please signify the release bundle on your PLIP. For a technical explanation see the "Using bundles for code review" paragraph of the "Version Control" page of this reference manual.

Once you've done developing it let the framework team know. At this point we'll do some things:

  • review it and check you've done what you said
  • see which release it will be accepted into

These are the criterias by which the framework team will review your review bundle:

  1. Does the PLIP itself need work?
    • i.e. is this idea well baked and expressed clearly
  2. Does the work proposed belong in Plone now, in the future?
    • Does it do the needful for Plone?
    • Is it more appropriate as a qualified add-on?
  3. What condition is the review bundle in:
    • tests
    • sane implementation
    • clearly coded
    • uses current idioms of development
    • documentation / doc-tests

Note that if you don't finish your implementation in time for the feature freeze, it will not be included in the next Plone release. You can always submit your PLIP for the next release.

Finishing your work

Once you have finished your work and it was accepted by the framework team and the release manager, you will be asked to merge your work into the main development line. Merging the PLIP in is not the hardest part, but you must think about it when you develop. You'll have to interact with a large number of people to get it all set up. The merge may cause problems with other PLIP's coming in. During the merge phase you must be prepared to help out with all the features and bugs that arise.

If all went as planned the next Plone release will carry on with your PLIP in it. You'll be expected to help out with that feature after it's been released within reason, and we look forward to the next feature.