Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? Then, the proposal: In Zope 2.12, acquisition wrappers are optional. Instead of using a wrapper, acquisition can work by following __parent__ pointers. That work well for views, where these are now set properly, but no content currently maintains __parent__ pointers. We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. We can't use the setitem() and uncontained() helpers directly, since these deal with containment proxies and have slightly different semantics, but I think we can do this: 1) Add the following to _setOb: def _setOb(self, id, object): if ILocation.providedBy(object): if not IContained.providedBy(object): alsoProvides(object, IContained) oldname = getattr(object, '__name__', None) oldparent = getattr(object, '__parent__', None) if id is not oldname: object.__name__ = id if self is not oldparent: object.__parent__ = self setattr(self, id, object) 2) Add the following to _delOb: def _delOb(self, id): """ Remove the named object from the folder. """ try: obj = self._getOb(id, _marker) if obj is not _marker: if IContained.providedBy(obj): obj.__parent__ = None obj.__name__ = None except AttributeError: # No need to fail if we can't set these pass delattr(self, id) Note that there's a slight discrepancy here with the way zope.container works. In Zope 3, the __parent__ pointer is not unset until after the ObjectRemovedEvent is fired. In Zope 2, we only fire that event after the object has been fully removed (in _delObject()), but we have the ObjectWillBeRemovedEvent that is fired before. I don't think this really matters, though. 3) It'd be nice to also make ObjectManager and BTreeFolder2Base support the IContainer interface, so that OFS containers can be used with the more natural dict-like API of Zope 3 rather than the somewhat obscure getattr()/_getOb()/_setObject()-vs-_setOb() and so on API we have now. To add this, we'd just need to add a few methods to ObjectManager that calls the existing APIs, e.g. __getitem__, __delitem__, __setitem__ and so on. We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 26 Apr 2009, at 16:53, Martin Aspeli wrote:
We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does.
Is there any risk involved in this? It looks ok in theory, just that we're at a4 of Zope 2.12, we should be getting wary of features.
We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily.
plone.folder is GPL and owned by the Plone Foundation, BTreeFolder2 is ZPL and owned by the Zope Foundation and contributors. This sounds like "quite easily" from a copy-the-code point of view, but doesn't take account of legal issues. You'd need at least a PF board vote. I doubt the Plone foundation is a Zope contributor, and I'm not sure if their agreements would even be compatible, it may grant Zope Corp some rights that weren't granted to the PF. Matt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 26.04.2009 um 18:16 schrieb Matthew Wilkes:
On 26 Apr 2009, at 16:53, Martin Aspeli wrote:
We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does.
Is there any risk involved in this? It looks ok in theory, just that we're at a4 of Zope 2.12, we should be getting wary of features.
We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily.
plone.folder is GPL and owned by the Plone Foundation, BTreeFolder2 is ZPL and owned by the Zope Foundation and contributors. This sounds like "quite easily" from a copy-the-code point of view, but doesn't take account of legal issues. You'd need at least a PF board vote. I doubt the Plone foundation is a Zope contributor, and I'm not sure if their agreements would even be compatible, it may grant Zope Corp some rights that weren't granted to the PF
The License-Locked-In effect? Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkn0jVUACgkQCJIWIbr9KYw6LwCgm2tdWpe2mHdZyobsb7mdSrgs JCYAoOUmoTtqTCVWqA/qHwwvsDxhnS/U =LNu3 -----END PGP SIGNATURE-----
Martin Aspeli wrote:
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ?
I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers.
In Zope 2.12, acquisition wrappers are optional. Instead of using a wrapper, acquisition can work by following __parent__ pointers. That work well for views, where these are now set properly, but no content currently maintains __parent__ pointers.
We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. We can't use the setitem() and uncontained() helpers directly, since these deal with containment proxies and have slightly different semantics, but I think we can do this:
1) Add the following to _setOb:
def _setOb(self, id, object): if ILocation.providedBy(object): if not IContained.providedBy(object): alsoProvides(object, IContained)
oldname = getattr(object, '__name__', None) oldparent = getattr(object, '__parent__', None)
if id is not oldname: object.__name__ = id if self is not oldparent: object.__parent__ = self
setattr(self, id, object)
2) Add the following to _delOb:
def _delOb(self, id): """ Remove the named object from the folder. """ try: obj = self._getOb(id, _marker) if obj is not _marker: if IContained.providedBy(obj): obj.__parent__ = None obj.__name__ = None except AttributeError: # No need to fail if we can't set these pass
delattr(self, id)
Note that there's a slight discrepancy here with the way zope.container works. In Zope 3, the __parent__ pointer is not unset until after the ObjectRemovedEvent is fired. In Zope 2, we only fire that event after the object has been fully removed (in _delObject()), but we have the ObjectWillBeRemovedEvent that is fired before. I don't think this really matters, though.
3) It'd be nice to also make ObjectManager and BTreeFolder2Base support the IContainer interface, so that OFS containers can be used with the more natural dict-like API of Zope 3 rather than the somewhat obscure getattr()/_getOb()/_setObject()-vs-_setOb() and so on API we have now.
To add this, we'd just need to add a few methods to ObjectManager that calls the existing APIs, e.g. __getitem__, __delitem__, __setitem__ and so on.
We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily.
+1 Laurence
Laurence Rowe wrote:
Martin Aspeli wrote:
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ?
I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers.
It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge. Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2. The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Laurence Rowe wrote:
Martin Aspeli wrote:
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers.
It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge.
Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2.
I doubt it would be all that difficult to change the publisher to handle unicode path segments.
The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though.
This is what I'm worried about. If new code uses __name__ instead, then it opens up the possibility to share ZODB content between Plone and lightweight systems like repoze.bfg, as well as making it easier for Plone to migrate to a cleaner content model. Plone has been around for eight years now, I sincerely hope we are not still stuck on OFS.SimpleItem for another eight years! Laurence
On 4/27/09 3:27 PM, Laurence Rowe wrote:
Martin Aspeli wrote:
Laurence Rowe wrote:
Martin Aspeli wrote:
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers. It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge.
Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2.
I doubt it would be all that difficult to change the publisher to handle unicode path segments.
This would be the only sane thing to do if Zope was being created today. It's a lot saner to store Unicode object identifiers than string ones, and if you've got that it's a no-brainer to use Unicode path segments too. But if you did one and not the other, it would be a worthless change.
The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though.
That's certainly keeping with the spirit of the default "bad identifier" regex in OFS, but it does feel a little weird to need to never use high-order characters in ids (even if you did need to make them utf-8 encoded). I had to work around this for one very large application that wanted to use Zope as a filesystem storage and it was no fun at all (in fact, it would have been sanest to not use Zope for that).
This is what I'm worried about. If new code uses __name__ instead, then it opens up the possibility to share ZODB content between Plone and lightweight systems like repoze.bfg, as well as making it easier for Plone to migrate to a cleaner content model. Plone has been around for eight years now, I sincerely hope we are not still stuck on OFS.SimpleItem for another eight years!
I wouldn't worry much about trying to preserve compatibility between Zope 2 and Zope 3/bfg at this level; it's highly unlikely that *any* Plone content object will work out of the box on any system other than Zope2 (or at least without a large chunk of Zope2 sitting around) due to abuses of things like "self.REQUEST" in Archetypes. But I could be wrong. - C
2009/4/27 Chris McDonough <chrism@plope.com>:
On 4/27/09 3:27 PM, Laurence Rowe wrote:
Martin Aspeli wrote:
Laurence Rowe wrote:
Martin Aspeli wrote:
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ?
I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers.
It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge.
Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2.
I doubt it would be all that difficult to change the publisher to handle unicode path segments.
This would be the only sane thing to do if Zope was being created today.
It's a lot saner to store Unicode object identifiers than string ones, and if you've got that it's a no-brainer to use Unicode path segments too. But if you did one and not the other, it would be a worthless change.
My point here is that if we modify the publisher then maybe we can start storing unicode __name__ attributes. Unicode container keys work just fine now so long as they contain only ascii characters.
The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though.
That's certainly keeping with the spirit of the default "bad identifier" regex in OFS, but it does feel a little weird to need to never use high-order characters in ids (even if you did need to make them utf-8 encoded). I had to work around this for one very large application that wanted to use Zope as a filesystem storage and it was no fun at all (in fact, it would have been sanest to not use Zope for that).
This is what I'm worried about. If new code uses __name__ instead, then it opens up the possibility to share ZODB content between Plone and lightweight systems like repoze.bfg, as well as making it easier for Plone to migrate to a cleaner content model. Plone has been around for eight years now, I sincerely hope we are not still stuck on OFS.SimpleItem for another eight years!
I wouldn't worry much about trying to preserve compatibility between Zope 2 and Zope 3/bfg at this level; it's highly unlikely that *any* Plone content object will work out of the box on any system other than Zope2 (or at least without a large chunk of Zope2 sitting around) due to abuses of things like "self.REQUEST" in Archetypes. But I could be wrong.
You don't have to write Archetypes to use Plone though. Tools like plone.app.content allow you to write sane, lightweight content types with zope.schema today. You need to bring in a lot of baggage in your base classes for things to be compatible with the CMF layer, but on the storage layer at least things are starting to look fairly sane. The acquisition changes in Zope 2.12 give us the possibility of writing clean new code without having to rewrite everything at once. Laurence
Now when we have eggs, can we fork the relevant modules (Publisher + OFS?) into two versions. Zope 2 backwards compatible versions, and versions that rely on that __parent__ is sane? Plone, and any others that want to gradually migrate to the toolkit, could then use that version. People who require backwards compatibility but need to more to Python 2.5/2.6 could use the old? 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. (Let the flaming begin.) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
Or, we could release 2.12 soon, and then start working on 2.13, a
+1. We need an eggified, Buildout-friendly Zope 2 that's fully compatible with Zope 2.11. Development after that should be smoother, since then we'll all be working with eggs. Shane
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. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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
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
Andreas Jung wrote:
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).
Ok. I'm in favor of keeping the wild mix of post 3.4 packages we have now in the versions.cfg and run with that. Going back to the 3.4 stable set and being stuck at Python 2.4 would be quite disappointing for me. Hanno
Hanno Schlichting wrote:
Going back to the 3.4 stable set and being stuck at Python 2.4 would be quite disappointing for me.
Me too, especially as I now have a Zope 2.12 project that's using lots of interesting Python 2.5'isms ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Tue, Apr 28, 2009 at 09:58, Hanno Schlichting <hannosch@hannosch.eu> wrote:
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.
I haven't run one single Zope project for at least 3-4 years that doesn't start up with screens of deprecation messages. It might be ugly, but it isn't really a significant problem. So I'll +2 my cents to Andreas 2 cents. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 28.04.2009 15:02 Uhr, Lennart Regebro wrote:
On Tue, Apr 28, 2009 at 09:58, Hanno Schlichting <hannosch@hannosch.eu> wrote:
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.
I haven't run one single Zope project for at least 3-4 years that doesn't start up with screens of deprecation messages. It might be ugly, but it isn't really a significant problem.
So I'll +2 my cents to Andreas 2 cents. :-)
And since Jim will release ZODB 3.9.0 beta soon (see zodb-dev list) we will see a 2.12.0b1 pretty soon (first half of May or so) - likely with the Zope 3.4 packages. Andreas
-----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@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-----
participants (10)
-
Andreas Jung -
Chris McDonough -
Chris Withers -
Hanno Schlichting -
Laurence Rowe -
Lennart Regebro -
Martin Aspeli -
Matthew Wilkes -
Shane Hathaway -
Tres Seaver