Raphael Ritz wrote: > Wichert Akkerman wrote: >> I seem to remember the plan was to target Plone 4 for CMF 2.2 and Zope >> 2.11, but as you can see below that does not appear to be possible.
Jens seems to have fixed a single statement that prevented the CMF 2.2 / Zope 2.11 combination just now. > So that means Zope 2.12 instead, right? I still think we should have a discussion about the Zope version to use. 2.11 is a pretty no-brain simple update that gets us ZODB 3.8 (blobs) and the last Zope 3.4 release with largely minor bugfixes and no real changes. There's really not much to anything in that release except for being slightly less outdated than 2.10. Zope 2.12 on the other hand is generally more ambitious, gets us the Zope Toolkit wild bunch, ZODB 3.9 (RelStorage support), Python 2.5 and 2.6 support, full eggification and with Acquistion redux a path out of Acquistion land. I think someone has to try and see what kind of changes are acutally required to make a current Plone 3.3rc3 run on Zope 2.12 or even better a real client side with a collection of add-ons. Otherwise we have a long list of desirable features without knowing what's the cost for it. > Generally speaking, I'm a bit uncomfortable with jumping > from Zope 2.10.x to 2.12.x as this will reduce the chances > of reacting to deprecation warnings which is of particular > importance for all our add-on developers. I'm afraid we'll > see lots of broken add-ons without prior warnings. One interesting thing to note here is that the concept of deprecation warnings has been abolished by the Zope community now. You won't get any deprecation warnings anymore at all, but import statements are left in place in old locations to give you some form of infinite backwards compatibility support. There might be a number of cases where those might have been forgotten, but those could be fixed. The intended new way forward is to use a not-yet-existing tool (possibly a mode in the test runner) that can warn you of imports from non-canonical locations. So if you feel like reducing your dependencies you can look at these and replace imports from some zope.app.foo packages with zope.bar potentially loosing the dependency on zope.app.foo. In general this might mean a much lower risk to upgrading than we fear. Hanno _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
