[Framework-Team] Plone 5 - rough roadmap

Hanno Schlichting hanno at hannosch.eu
Mon Mar 15 10:18:13 UTC 2010


On Mon, Mar 15, 2010 at 10:13 AM, Alexander Limi <limi at plone.org> wrote:
> We could also take a page from how Firefox is looking to change their
> release management strategy, ie. landing stuff that has only infrastructural
> impact in a 4.x release (out-of-process plugins in FF's example, which will
> land in the 3.6 series, for Plone 4.x, it could be something like WSGI).

I think we can introduce some technologies already in 4.x releases,
but make them opt-in. For example shipping Chameleon but disabling it
by default. We will only get WSGI with a new Zope 2 release, which
will bring a number of other changes with it, among those another
basket full of updated Zope Toolkit packages. It's yet too early to
say what these changes will be. Maybe we can upgrade to Zope 2.13, but
that depends a lot on how Zope 2 maintenance and development will
proceed and how the ZTK will play out.

One thing to be aware of, is that in contrast to Firefox nobody uses a
bare-bone Plone, but we are highly dependent on our add-ons. And
that's not just two dozen most often used ones. We have therefor been
careful not to break any add-ons during a major release cycle.
Unfortunately all our major framework level changes have a tendency to
just do that.

> Of
> course, that's what we're already doing, but pushing the less risky parts
> that were previously considered only for Plone 5 might be a good approach,
> and reduce risk. Landing too much at once in Plone 5 is definitely a real
> risk, as is a too-long release cycle for Plone 5. So evaluating each of the
> things we land in Plone 5 for possible inclusion in a future 4.x release is
> probably a good tactic.

Sure. We can split some of these up. But I don't think we can include
either Deco/Blocks, xdv or Dexterity as a whole into any 4.x release.
Changing the default story for any of those areas is too much a
change. That's why I like them to follow Dexterity's lead and push
down parts of them into 4.x releases. Stuff that makes their life
outside the core easier. And both Deco/Blocks and xdv still have to
prove themselves in real production projects outside the core.
Dexterity has yet to work out its evolution story for Archetypes based
add-ons and content.

> I'd love to see a shorter release cycle for Plone 5, but as usual, it's hard
> to determine, and I don't think the currently suggested estimates are
> unreasonable.

Oh yeah, my schedule is realistic, but not inspiring or visionary in any way ;)

> I think an increased focus on "Tech Preview" releases (ie.
> what alpha used to mean :P ) could provide useful checkpoints for people to
> rally around when it comes to development. We shouldn't underestimate the
> power of self-imposed deadlines, I think it was used well in the Plone 4
> release cycle, and even if Plone 5 is a release with a longer release cycle,
> we should try to do several checkpoints along the way to avoid landing too
> much at once, and get stuff out there for people to test in carefully
> managed projects, similar to what Jarn and others have been doing for Plone
> 4.

I had some idea about doing some more longer running agile process
initially for "my Plone release". But it turned out that this doesn't
work with any of our processes or how volunteers can pledge their
time. We are going to have one PLIP review cycle for Plone 5.0. Once
that process starts, we have a couple of months to go, until we hit a
feature freeze and some more weeks or months until we have fixed all
the bugs. But that means that any major PLIP needs to be ready before
we start the PLIP process. Another thing I learned from all my
experimental changes, is that we can only merge things to trunk, once
they are really finished or some of the more unstable changes can
bring the entire release to a halt.

So if we want to ensure that some of those big changes make it into
Plone 5, the only variable we have, is to start the PLIP process at an
appropriate time. Once that process starts, it's going to be all time
based and we'll release whatever is ready by the end of the PLIP
process.

So my timeline tries to give those major changes a chance of making it
into Plone 5. But that means we aren't going to work on the official
Plone 5 release at all for the next 12 months. There won't be any code
for the official Plone 5 for a long time. All interesting work will
have to be made in add-ons outside the core. And the process for that
work needs to be driven by interested people on their own terms.

Just my take on this,
Hanno




More information about the Framework-Team mailing list