Would it make sense to have Zope 2.8 include all of the packages below other than zope.app and for Five to supply it's own zope.app?
It would make life harder for Five, and create more work for us, as we'd have to worry about:
* shipping a zope.app ourselves (does it contain binaries? will it ever contain binaries? Right now we can just lift along ZopeX3 releases)
* we'd have to worry about version skew. Suddenly we're locked into whatever versions of the Zope 3 code is in Zope 2.8 and whatever version of zope.app that works with that version. Right now Five is completely free to track ZopeX3 releases and there is no worry about version skew.
If there is a knob to turn off anything Zope 2.8 ships then life would be a bit harder for people installing Five, as it'd need an extra zope.conf switch besides the path to Zope 3 that already needs to be there. It's doable to document this though.
As to Five, this whole exercise, no matter what packages are copied, only makes life harder, not easier. I was looking to go this way (including more zope 3 stuff into zope 2) a year ago, and decided I couldn't make progress that way, as I had to wait for all kinds of things I couldn't control easily, like Zope 2.8 and the Zope 2+3 interface compatibility package.
Then I got to liberate zope.interface from the one incompatibility that really prevented Five. After that, Five was ready to be freely developed, independent of the unpredictability of Zope 2 *or* Zope 3 releases. Any addition of Zope 3 code to Zope 2 will make life harder there.
I understand that for a future version of Zope 2, Zope 3 code will be included.
I understand one direct use case is some Zope 3 persistence system that can be used to help with ZClasses.
I understand one other set of use cases is to make it possible to start using Zope 3 technology in Zope 2 (this use case could also be fulfilled by something like Five).
I can also see an ease of deployment use case -- no huge Zope 3 package to download and install separately. Then again, such a separation between the projects does make life easier sometimes, as is evidenced by the trouble Five would get in with more mixing.
What other use cases are floating around?
I cannot judge how likely version skew is between zope.app and the parts of the zope package that will be in Zope 2.8.
Anyway, more work for Five developers doesn't mean this shouldn't happen, but perhaps a review of the use cases driving this would be helpful. If it's really only about making ZClasses work in Zope 2.8, is this really the only way forward? If not, I'd prefer to stick to the original plan, and wait for Zope 2.9 before Zope 3 integration starts to happen.
Regards,
Martijn
_______________________________________________
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 )
