Plone 3.1 timeline

[Wichert Akkerman]

In coordination with the new framework team I am happy to be able to announce the timeline for the next Plone feature-release: Plone 3.1. The release process for 3.1 has very specific goals:

Safe changes only: since this is a minor release which should not destabilize Plone 3.x only changes that are risk-free will be considered. This means that no or very minimal migration steps are allowed, everything has to be properly tested, documentation has to be in order and the user interface has to be finalized. This also means that 3.1 will be based on the 3.0 codebase: Plone trunk has far too many major changes already.

Do not overload the framework team: the deadlines are fast and strict, so making it easy for them to rest proposals is important. The best way to do that is to create a buildout based on the latest Plone 3.0.x release and include only the changes relevant for that proposal.

Quick release schedule: we do not want to take 9 months to get this release it. This means that all proposals have to be completely done and polished in order to be acceptable. The migrations, if any, have to be in place and working, there have to be working tests and the user interface must be complete.

This is the timeline for 3.1:

  2007-12-14 : PLIPs for all features have to be finished and submitted
  2007-12-21 : framework team gives verdict on PLIPs only, not an implementation
  2008-01-19 : review bundles have to be submitted to the framework team
  2008-02-02 : framework team completes reviews
  2008-02-08 : 3.1 pre-release tagged
  2008-02-11 : 3.1 pre-release with installers released
  2008-02-15 : 3.1 release candidate tagged
  2008-02-18 : 3.1 release candidate with installers released
  2008-02-29 : 3.1 final tagged
  2008-03-02 : 3.1 final with installers released

Note that there is a change from the procedure we used for Plone 3.0: there is now an extra PLIP-review step. This has been added to allow us to check of a proposal is not too invasive or for some other reason undesirable for 3.1. That makes sure that nobody will be trying very hard to make a deadline only to hear that their work is not going to be considered.

As you can see this is an ambitious schedule. This means that we have to be very strict in what will be accepted and what won't. There is no shame in missing a deadline - we are all busy people and sometimes a deadline is just not attainable. Anything that does not make it in can be reconsidered for 3.2 or 4.0.

Wichert.


-- 
Wichert Akkerman <wichert at wiggy.net>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.