[Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Hanno Schlichting]

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