#10776: Update to Zope 2.13
----------------------------+-----------------------------------------------
Reporter: hannosch | Owner: hannosch
Type: PLIP | Status: closed
Priority: minor | Milestone: 4.1
Component: Infrastructure | Resolution: fixed
Keywords: |
----------------------------+-----------------------------------------------
Changes (by hannosch):
* status: assigned => closed
* resolution: => fixed
Old description:
> '''Proposer:''' Hanno Schlichting[[BR]]
> '''Seconder:''' None as yet
>
> == Motivation ==
>
> 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.
>
> == Assumptions ==
>
> 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.
>
> == Deliverables ==
>
> See Proposal above.
>
> == Risks ==
>
> 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.
>
> == Participants ==
>
> Hanno Schlichting <hannosch>, Zope 2 release manager
>
> == Progress ==
>
> A basic buildout configuration is already present. Last I checked all
> tests of Plone passed with this configuration.
New description:
'''Proposer:''' Hanno Schlichting[[BR]]
'''Seconder:''' None as yet
== Motivation ==
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.
== Assumptions ==
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.
== Deliverables ==
See Proposal above.
== Risks ==
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.
== Participants ==
Hanno Schlichting <hannosch>, Zope 2 release manager
== Progress ==
The PLIP was merged on November 17, 2010.
--
--
Ticket URL: <http://dev.plone.org/plone/ticket/10776#comment:23>
Plone <http://plone.org>
Plone Content Management System
_______________________________________________
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories
