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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

At the moment, the Zope 2 package set it defined here:

 http://svn.zope.org/Zope/trunk/versions.cfg?view=markup

I don't see any reason to hold up a 2.12 release while the ZTK
stabilizes:  in fact, I think the existince of a stable 2.12 release
with a known package set may be a prerequisite for getting there.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9xI2+gerLs4ltQ4RAjEAAKCmpxhaxX6NDuhrAAmnLdLh1/RLVQCgxlc8
4JQYuT+aGmNfqCWkudPDovw=
=drGg
-----END PGP SIGNATURE-----