[Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martin Aspeli]

Martijn Faassen wrote:

> As I pointed out, it is effectively inaccessible for Plone users anyway, 
> as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 
> libraries just like that and expect anything to work.

Why not? We upgrade Zope 3.3 packages to 3.4+ all the time to access bug 
fixes or new features. It's rarely completely painful, but once you've 
got an understanding of what versions work and don't work together, you 
do have the option of selectively upgrading parts of the zope.* namespace.

Also, I'm expecting there to be completely new packages that are not a 
like-for-like replacement of the Zope 3.3 set. Whether these would work 
is of course a case-by-case evaluation. But let's not make it a no by 
default, unless there's a good reason.

> There are no such new and more focused components even on the drawing 
> board yet. I highly doubt that the first release of the Zope Toolkit 
> will contain such components.

What about packages that build on the ZTK? Stephan just gave a great 
example with z3c.form. Surely, that's the kind of innovation and code 
sharing we want to encourage.

>> We're not comfortable moving to Zope 2.12 for the 3.x 
>> series. We may be able to move to Zope 2.11, which *may* work with 
>> Python 2.5, but this is not clear.
>>
>> That makes the potential user base for new-and-dependency-isolated Zope 
>> components quite a bit smaller. 
> 
> I don't believe in this Plone (for *existing Plone releases*) user base 
> anyway, so I don't think it's getting smaller.

I think you're wrong about that.

For example, the known-good-set of packages required to get Dexterity 
1.0a1 to install on Plone 3.3 will look something like this:

http://good-py.appspot.com/release/dexterity/1.0a1?plone=3.3rc2

Most of the zope.* upgrades there are caused by a z3c.form dependency, 
plus z3c.relationfield.

> If we'd have released a Zope 3.5 that didn't have Python 2.4 support, 
> would you have complained that you cannot use Zope 3.5 with an existing 
> Plone release?

Yes.

> This is the same as trying to use Zope 3.4 and Zope 3.3 components 
> together (though the changes from Zope 3.4 to the Toolkit are *bigger* 
> as we move things around). It *might* just work in some cases, but it's 
> unlikely it will.

It does. ;)

And Plone is likely to see Zope 2.11 (which uses Zope 3.4) before 2.12. 
As far as I know, Zope 2.11 is still supported only on Python 2.4, but 
being based on Zope 3.4, we are much closer to ZTK as a starting point.

Typically, there'll be three reasons to upgrade packages:

  - either, we depend on a bug fix (quite common, e.g. with zope.i18n)
  - or, we depend on a package that depends on a newer version of a core 
package that's backwards compatible (c.f. z3c.form)
  - or, we need a new feature (less common, in practice)


> Sorry, I won't let you turn this back around again. :) Arguments for 
> increased maintenance burden will need to be realistic.

What is the increased burden?

I mean, are we feeling this pain today? Do we have evidence that we'll 
be feeling it going forward?

I'm not saying your argument is invalid - instinctively, it makes a lot 
of sense. But it feels like we're taking that argument for granted with 
little actual evidence and justification, and ignoring the 
counter-argument as invalid, which makes this conversation a bit 
difficult to have.

> I will note that Grok 1.0 won't work with the Zope Toolkit either; we're 
> sticking with Zope 3.4. Only after 1.0 will we go over to the toolkit.

Right. And Plone won't ship with ZTK by default for a while yet, I 
reckon, but we want people to be able to use the new code and experiment 
with it early and often.

> It is, but again, it's just wishful thinking that the toolkit libraries 
> as they are released today will work in combination with a existing 
> release of Plone.

I hope that's not true. It'd probably be true if ZTK packages have no 
regards for BBB with older versions of the library. If that's the case, 
you really should rename the packages in question, though. I once recall 
Jim saying "the more I think about it, the more I think we can just 
never break backwards compatibility". That's the way it works in many 
other platforms, e.g. Java and .NET. And Python, maybe. Why do we have a 
urllib2? :)

Martin


-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book