this is your Zope 2 release manager speaking. We had some discussion in the community about the roadmap ahead for the next Zope 2 release culminating in a plan today.
A first alpha release for Zope 2.13 will be released on June 25 - just over 10 days from now. More alpha releases will follow on a 3-4 weeks basis and a first beta will be out in early September. That is as usual without guarantees and subject to changes. A final release is expected later this year.
Zope 2.12 is continuing to be maintained. A Zope 2.12.7 bugfix release was released just yesterday.
Current Zope SVN trunk (which will become 2.13) is compatible with both CMF 2.2 and CMF trunk and the upcoming Plone 4. It is likely that Plone 4.1 will officially support Zope 2.13.
Zope 2.13 will bring a couple new features and has done a large deal of refactoring and house keeping. It currently only supports Python 2.6. Support for Python 2.7 might be added, if there is community volunteers to do the required work. Python 3.x support is out of the scope. Work has begun to port some of the underlying zope packages to Python 3.x, but there's still a lot more to do before this is feasible for Zope 2 itself.
So what's in it?
Zope 2.13 doesn't have any zope.app.* dependencies anymore. This finishes the transition from the hybrid Zope 2 + 3 codebase. Zope 3 itself has been split up into two projects, the underlying Zope Toolkit consisting of foundation libraries and the application server part. The application server part has been renamed BlueBream. Zope 2 only depends and ships with the Zope Toolkit now. Large parts of code inside Zope 2 and specifically Products.Five have been refactored to match this new reality. The goal is to finally remove the Five integration layer and make the Zope Toolkit a normal integral part of Zope 2.
Zope 2.13 comes with native WSGI support. First pioneered in the repoze.zope2 project, this capability finally found its way back into the core and obsoletes the externally managed project. With WSGI Zope 2 can natively talk to a variety of web servers and isn't restricted to its own ZServer anymore. It also opens up new possibilities for writing or reusing middleware in Zope 2 or factoring out capabilities into WSGI endware. It's expected that this new deployment model will over time become the default and the old ZServer implementation will be deprecated. There's no concrete timeline for this yet.
There's an ongoing effort to refactor Zope 2 into more independent modularized distributions. Zope 2.12 has already seen a lot of this, with the use of zope.* packages as individual distributions and the extraction of packages like Acquisition, DateTime or tempstorage to name a few. Zope 2.13 continues this trend and tries to externalize packages containing C extensions. In a not so distant future it should be possible to run a Zope 2 like environment without the ZMI and the corresponding code. This is part of the vision for Zope 2 to evolve into a more modern and maintainable codebase, while preserving a realistic gradual upgrade path for existing installations and projects based on it. The Zope 3 project has shown that a complete rewrite is no viable answer for a large class of existing software.
There's a large number of smaller features and improvements in the underlying libraries and Zope 2 itself. For example Zope 2.13 will ship with the new ZODB 3.10 version, which sports some noticeable performance improvements. The move to the latest version of the Zope Toolkit libraries makes integration of Zope community projects like z3c.form much easier.
After the rather long release periods of Zope 2.12 and 2.13 we expect to switch to a shorter release period of six to nine months for the upcoming 2.14, 2.15 and beyond releases.
Discussion of the Zope 2 core development takes place on the zope-dev mailing list. Feel free to engage, leave comments on this blog or contact me in private.
Your release manager,