[Framework-Team] Re: Plone 4 dependencies
hannosch at hannosch.eu
Tue May 26 09:59:58 UTC 2009
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
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.
More information about the Framework-Team