My 2 cents: Zope 2.12 will go into beta state as soon as ZODB 3.9.0 goes beta. The underlying Zope 3 packages are stable and good enough right - I don't care much right now about having an official Zope Toolkit Release 1.0. If this will happen soon: fine - otherwise we will stay with the current Zope 3.4 packages. With Zope 2.12.0b1 we will look at the state of the ZTK and make a final decision (3.4 vs. ZTK 1.0). This decision will then be final for the 2.12 release. People will be free to use the ZTK later on their own risk by overriding the versions or by providing a dedicated index Andreas On 28.04.2009 9:58 Uhr, Hanno Schlichting wrote:
Chris Withers wrote:
Lennart Regebro wrote:
Or, we could release 2.12 soon, and then start working on 2.13, a version that explicitly is for people who want to move towards the Zope Toolkit, and may not be completely backward compatible.
This would be my vote.
Right now the story for features in Zope 2.12 is at http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html and has the following items:
- Support for newer Python versions - Fully eggified - Zope Toolkit - ZODB 3.9 - Module cleanup - Documentation updates - Acquisition redux - Object managers and IContainer
If I understand some people correctly, they want "Fully eggified" over all others.
The risky and mostly undefined item on the list is the "Zope Toolkit". While ZODB 3.9 isn't finished yet, it is close enough to not cause any major trouble. So which of the three options do people want, when it comes to the included Zope packages:
1. Stable - meaning use the same as Zope 2.11 does (== Zope 3.4) 2. Zope Toolkit 1.0 (whatever that is) 3. A newer mix of Zope packages, which particular mix isn't shared with anyone else
There are some bad implications for all of these items:
1. The stable option also looses us support for newer Python versions. It is only very recently that packages got full deprecation warning less support for Python 2.5 and 2.6. With Zope 3.4 we are stuck with Python 2.4.
2. The Zope Toolkit 1.0 isn't defined yet and will delay any kind of beta release by some more undefined time.
3. The kind of wild mix of Zope packages we have right now is hard to maintain, as nobody else is testing the particular combination in any way and ongoing refactorings cause subtle breakage all the time.
My personal vote still goes for option 2. What that means is trying to establish a more minimal set of packages and declaring a particular version soup of that mix as "stable". In order to get this done, we need someone other than me trying to do the actual work of defining such set of packages and the steering group to make a decision about the scope of a 1.0 release. I'm all in favor of declaring whatever we basically got now as a good 1.0 release and then continue to work on a Zope Toolkit 2.0 where an exclusion of the ZMI bits and maybe the zope.app.publication and friends refactorings are major work items.
Speaking from the Plone perspective, a Zope 2.12 release that is released as soon as possible has no particular value. No official Plone version would use such a release and with the kind of changes we have, it's unlikely that any Plone 3.x version will work with it.
Hanno
_______________________________________________ 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 )
-- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting