[Framework-Team] [plone4] Release process

[Hanno Schlichting]

Hi.

As the not-quite-yet release manager for Plone 4, here is my general
plan on how to release Plone 4.

- Plone 4 will be primarily a feature based release, not time-based

We need to address various major problems with Plone of which some will
block a new release from my point of view. For example noticeably
increased performance, unifying similar concepts (portal skins vs.
Zope3, viewlets vs. macros vs. portlets), a better page composition
story (no more folder_listings, display menu) and a leap in our
technical base (Python 2.6 and WSGI).

The possibility to easily use a non-Archetypes based content type story
is blocking a new release for me as well. Switching to a new default
story is something I don't consider possible in the next year right now,
but might be convinced otherwise.

We will need to restrict the time as well, to get to a final release at
one point. My current plan is to aim for about one year until a final
release. A first "beta" release closely before the Plone conference
would be good to have.

- Plone 4 will be released based on an agile approach

Managing a software release of a year where everything is merged in just
before a beta deadline doesn't work in commercial projects. I think it
doesn't work in open-source either. Therefor I want to use an agile
approach for the next release. This means I want to get Plone to the
point where we use iterations (probably about two months) and make sure
we have a working software at the end of those and ship them as a
preview release.

I'll be allowing not-yet-fully finished features to be included into
those technology previews. If the documentation for a change is not yet
updated, we can already include it. If the documentation isn't updated
in the next iterations, we can remove the feature again from the
codebase. Inclusion into a release can happen on the basis of trusting
the developer who did the change to follow up on it and maintain it. If
he doesn't, we can remove a feature again from the codebase.

- Plone 4 will have a documented upgrade story

A migration from Plone 3 to 4 does not need to be possible in an almost
fully automated fashion. We need to ensure we have an easy to follow and
understandable documented upgrade story. If we for example change API's
or rearrange code, we can document the new places in writing and with
error references for the most commonly used parts. If you need to change
your buildout configuration, a document explaining the changes is fine,
we don't need to build an upgrade machinery for configuration files.

Comments? Anything else people want to know at this point?

Hanno