On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli <[email protected]> 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 _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
