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 <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
