Ticket #10776 (closed PLIP: fixed)
Update to Zope 2.13
|Reported by:||hannosch||Owned by:||hannosch|
Description (last modified by hannosch) (diff)
Proposer: Hanno Schlichting
Seconder: None as yet
Zope 2.13 is the next stable release of Zope 2. It comes with a new and faster version of the ZODB, support for Python 2.7, built-in WSGI support, updated Zope Toolkit packages and a much faster ZCatalog. It also makes all of zope.app.* optional and has a number of internal cleanups. You can read more about it at http://docs.zope.org/zope2/releases/2.13/WHATSNEW.html
In the past Plone has had a very conservative update policy towards upgrading Zope 2 releases, which has frequently led to a mismatch between the Zope distributions Plone shipped with and those developers wanted to use. This is again the case for Plone 4.0 and developers relying on for example z3c.form.
With Zope 2.12 we have gotten a fully eggified Zope release including all Zope Toolkit distributions. This has made it much easier to selectively upgrade individual distributions. In practice this currently does not work. In the refactoring of Zope 3 into the Zope Toolkit there's been a massive amount of interdependent changes to all distributions and a bulk of new distributions. Upgrading individual distributions without getting the whole has become impossible, without risking subtle and sometimes critical breakages in unexpected places. There's many distributions were even using new supposedly bug fix releases isn't possible [see http://download.zope.org/Zope2/index/2.12.11/versions.cfg for a list].
Zope 2.13 solves this issue by updating to a real and stable Zope Toolkit release. This release is also used by both BlueBream and Grok and thus has a higher chance of being kept stable and maintained over a longer period. Sharing the same version set with Grok also makes it possible to use Grok technologies inside Zope 2 / Plone in a sane way. z3c.form is another example of a library that needs more recent versions of Zope Toolkit libraries than those provided in Zope 2.12.
While Zope 2.13 does a leap forward in the provided Zope libraries, virtually all of them are 100% backwards compatible in their API's. A demonstration of this is that both Plone 4.0 and CMF 2.2 work with Zope 2.13 without any more modifications (some modifications where required in the test runner, which interacts with many internals).
The classic Zope 2 code itself is being factored out into multiple distributions in the 2.13 release. Going forward this trend will continue. This will allow us to both quickly pull in new bug fix releases of things like DateTime or Products.MailHost and with Zope 2.14 and going forward to drop unused parts of Zope 2 from Plone. For example ExternalMethods and PythonScripts will be entirely optional in 2.14. five.formlib integration and Products.ZSQLMethods are already optional in 2.13.
While Zope 2.13 provides native WSGI functionality, it is outside of this PLIP to make use of this in any way. There's a large number of open questions around WSGI and the changes it requires to instance creation and setup, which warrant their own PLIP. A good number of those will also have an impact on the Zope 2 codebase itself, which is going to be already past a beta release by the time this PLIP gets started and thus will have to wait for Zope 2.14. I expect to see more community experimentation being done with WSGI once the capability is there. We might see a PLIP for Plone 4.2 to see those experimentations being solidified into good practice, standards and documentation.
Proposal & Implementation
A PLIP config is available at https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10776-zope213.cfg.
While Zope 2.13 itself is still changing, there might be more minor changes required to the Plone codebase. Those are to be provided in PLIP branches, when they aren't backwards compatible and truly minor in scope. It will also help to review all remaining use of zope.app packages in Plone itself and use their zope.* replacements instead. In order to keep backwards compatibility with add-ons, Plone should extend the zopeapp.cfg configuration file, which provides version pins for all zope.app.* distributions.
See Proposal above.
While the changes to the Zope Toolkit packages should be all backwards compatible, there's a chance that some of them might cause problems. Generally most of the changes to zope.app.* packages where in code and configuration neither used nor usable inside Zope 2 and Plone. Naturally these can cause no trouble.
Some of the changes in Zope 2 itself might cause problems with tests and their interactions with internals. As Plone 4.0 already broke many of these without fixing them, I consider this to be acceptable. I'm assuming that we will see a PLIP for plone.app.testing to make it into 4.1, which should provide a clean new base for tests. PloneTestCase based tests and the various sorts of layer setups we have seen, are just too broken to be fixed in a reasonable way.
Zope 2.13 is currently in late alpha with a beta scheduled for early September. The code is already stable and could be released as a final almost at any point. It's therefor unlikely that a delayed Zope 2.13 release could delay a 4.1 release.
Hanno Schlichting <hannosch>, Zope 2 release manager
The PLIP was merged on November 17, 2010.
comment:23 Changed 5 years ago by hannosch
- Status changed from assigned to closed
- Resolution set to fixed
- Description modified (diff)