[Zope-dev] Zope 2.13 roadmap

[Hanno Schlichting]

On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli <optilude+lists at gmail.com> wrote:
> What's the next step? I'd love to see some roadmapping ala that you did
> for Plone 5, in particular to discuss our WSGI story (which I'm
> interested in helping out with if others can help too).

There's no big roadmap yet, but I have some ideas :)

In general I'd like to avoid a major Zope release, that isn't used by
an official Plone release. Zope 2.11 hasn't seen much attention and we
had to maintain 2.10 anyways. But if there's a decent and stable
feature set that other consumers like to get there hands on, we can
get them a release. I just won't be pushing into that direction.

Here's what I can see today:

There's a bunch of stuff already done as noted in
http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?view=markup.

- zope.app removal

This project is all finished. Zope2 doesn't contain any trace of
zope.app or the name Zope 3 in itself nor its dependencies anymore.

- Moving formlib out of the core

Triggered by the above and finished as well. Zope trunk doesn't
contain any trace of formlib anymore. The relevant code is now in the
five.formlib package. This package is also included in Zope 2.12, so
you can start using the functionality and be compatible with both Zope
versions. CMF does this already.

- WSGI

I cannot tell at the moment. It's going to depend on the actual
changes required to get this to work. Since there is some broken WSGI
support inside the 2.12 codebase, we can claim a certain deal of
changes as bugfixes. But there's limits to what we can warrant as a
bugfix. If the code changes are self-contained and only touch the
broken WSGI modules, we are good. If we require changes all over the
board for whatever reasons, this will have to be a new feature and go
into Zope 2.13. Only a branch with actual code will tell :)

- ZTK

As long as there's no formal release of the ZTK or a defined and
stable process around it, Zope 2 defines its own KGS. It so happens to
use exactly the same versions as the current ZTK trunk. Once we are
making progress on the ZTK release, we'll see how Zope 2 can use such
a release. My current guess is that Zope 2.13 will use some ZTK 1.1
release.

- Five deprecation

I did a whole bunch of work on this already and keep working on it.
The end goal is to be able to deprecate the entire Products.Five and
phase it out of the core. Actually useful functionality in it, is
integrated into the proper places inside the Zope2 core packages
instead. Like security stuff in AccessControl, container events in
OFS, reading site.zcml and setting up the CA in Zope2/App and so
forth. There's a number of hard cases, where there's some semantic
differences between zope.* packages and their Five equivalent,
especially in the "browser" realm. This project might not be
completely finished for 2.13. And yes, there's some difficult
questions with non-obvious answers around this. We'll deal with them
once we get there. I'm focussing on the obvious parts first.

- Reduce C code in Zope 2

My first part of this was discussed and implemented. The remaining C
code inside the Zope 2 distribution is in AccessControl,
DocumentTemplate and ZCTextIndex. We'll see what to do about them,
once their packages are actually self-contained.

- Make Zope 2 more modular

This is related to the above two points. I'm not quite sure about the
details of the implementation yet. But in general it would be nice, if
a consumer of Zope 2 could use it's core, without getting a whole
bunch of stuff it doesn't want. The obvious example here is Plone,
which continues to use less and less code from Zope 2, but has no
chance of making a radical cut and loose it all. There's interesting
problems, like being able to use Zope 2 without the ZMI. In some sense
this is similar to using the ZTK instead of zope.app. The only thing I
know for sure, is that I'd like to first make the packages inside Zope
2 standalone and reusable and only once they are, break them into more
distributions. We've gone the other way around with Zope 3 and it has
cost a whole lot of pain.

- ZODB 3.10

Jim promised a second alpha release to be out shortly. Should be low
risk to upgrade to it. The multi-threaded ZEO server promises some
good improvements.

- Python 2.7

This would be 2.7 support in addition to the existing 2.6. Last time I
checked all Zope 2 tests passed. But there where some hairy looking
test failures in zope.proxy and some more in RestrictedPython.
RestrictedPython will also need a new security review to make sure it
continues to work with 2.7.

- Python 3.x

Not on the agenda. We'll need to tackle this on the ZTK level first.


For an actual timeline, it seems autumn this year is the earliest any
2.13 could come out, so it properly supports Python 2.7 and we have
something definitive on the ZTK matter. But I'm not going to rush this
and it's somewhat more likely we'll end up with an ever later release
and match the Plone 5 release schedule.

All that said, we'll change plans if something comes up and a better
plan suggests itself. The above list is obviously non-exclusive, so if
someone else has anything he wants to work on, announce it, discuss it
and we'll decide when and how it gets in.

Cheers,
Hanno