On Tue, May 5, 2009 at 8:07 AM, Martin Aspeli <span dir="ltr"><<a href="mailto:optilude%2Blists@gmail.com">optilude+lists@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Lennart Regebro wrote:<br>
> Can you expand on this argument, because I don't understand it. Zope<br>
> 2.10 doesn't stop working because Zope 2.12 no longer supports Python<br>
> 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as<br>
> Zope 2.10 uses Zope 3.3 rather than Zope Toolkit.<br>
<br>
</div> - I think that as a principle, dropping support for a Python version<br>
that's commonly used in our community, should be a decision that<br>
requires a strong argument *for*, not a strong argument *against*.<br>
<br>
- The Zope Tool Kit aims to be a bridge between our different<br>
communities, and possibly other communities that may want to consume<br>
Zope software (are all of those using Python 2.5?). That means that<br>
those of us who are not in a position to move to Python 2.5+ soon<br>
deserve to be heard. Of course, Plone's point of view shouldn't be<br>
overriding to other concerns, but see point 1.<br>
<br>
- If you count the "Zope community" as those who also maintain Zope 2,<br>
we need to recognise that there's been no viable way for Plone to get to<br>
Python 2.5 until now, and the other changes in 2.12 mean it's not<br>
feasible to upgrade to it in the 3.x series. This is nobody's fault, of<br>
course, but it does leave a chasm that'll only widen as time goes on.<br>
<br>
- Once the ZTK is decreed to no longer need to support Python 2.4, I<br>
suspect no new development on the Zope platform will bother with it<br>
either. That means users of Plone can't use these packages. That in turn<br>
deprives those Zope packages of testers and potential contributors.<br>
<br>
- We are using Zope 3.4+ packages successfully with Zope 2.10 right<br>
now. I don't see that the ZTK will be any different. In fact, ZTK should<br>
help here, because we're getting a saner dependency structure.<br>
<br>
The Plone community is working hard to move to Python 2.5, but reality<br>
is we won't get there for another 12-18 months, in part because Zope<br>
2.12 is only now entering alpha and incorporates a lot of other (good!)<br>
changes that we need more time to integrate and work out a migration<br>
story for.<br>
<div class="im"><br>
Martin</div></blockquote><div><br>+1<br><br>Speaking from the context of my own primary zopey project (Py2.4-only OpenCore, which depends directly on Plone and increasingly on various zope.* packages) and as a user of Plone, I hope that the main-line ZTK would continue to support Py2.4 for a while longer. Announcing a "dropping Py2.4 support" deadline of, say, a year from now would give those of us still on Py2.4 time to prepare for that future, whether by getting our products onto 2.5 in time, or by gathering together a community to maintain 2.4-compatible versions of the necessary packages.<br>
<br></div></div>I think that in the medium term, maintaining 2.4 support (at least during a smooth transition period) could theoretically *lower* the ZTK maintenance burden significantly -- for example if the Plone community has the ability to experiment with newer versions of the ZTK or ZTK packages than Zope2, this could provide forward momentum for Zope2's own ZTK dependency as the results of those experiments feed back upstream to Zope2's stable KGS.<br>
<br>I know we're talking about unspecified future additions to a still fuzzy set of packages, so, to be as concrete as possible, I've been increasingly hoping to track at least zope.i18n development as closely as possible in OpenCore, using the ZTK/Zope2/Plone KGSes as a baseline rather than a hard requirement. I've been looking forward to trying out other packages in that context as well as the ZTK and dependency unravelling makes casual experimentation easier.<br>
<br>egj<br>