Lennart Regebro wrote: > This is only mildly confusing. It can also only get better with time, > as Plone seems to continue away from Zope 2 and onto the framework, > which means we in the future may end up with Plone, Grok and BFG being > app servers on the Zope Framework.
The current line of thinking for Plone is about this: Plone 4 will still run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2 anymore at all. We can all guesstimate on what kind of timeline that will mean. So it's highly likely that Zope 2.12 is the last release of Zope2 that Plone is going to use. Maybe a Zope 2.13 once Python 2.7 is released might be of interest to Plone. But otherwise I don't see any reason for a new Zope 2 feature release anymore from the Plone perspective. Plone is going to continue to use selected Zope libraries as everyone else, but use Repoze or just general Python packages from all over. Personally I want to move Plone from zope.i18n to Babel for example. We are not bound by names or frameworks in our package choices. > I also think all applications should move over to using repoze by > default. BFG already does so, of course, and Plone 4 is set to do so. > Hopefully by Zope 2.13, the old publisher can be a horrid memory, and > repoze.Zope2 be default. I don't know if there's going to be anyone, who is going to drive Zope2 itself forward into WSGI land. Plone is just switching to repoze.zope2 and bits of zope.pipeline by itself. The kind of radical and backwards incompatible changes an application like Plone can do, give us much more flexibility here, compared to the more conservative approach a framework needs to have. Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
