Christopher Lozinski wrote:
I do like the idea of ZClasses as a separate product.
Good! Then let's move it out of the Zope 2 trunk.
Actually I think all of Zope should be an assembly of separate products. I would love to see multiple flavors of Zope each as an assembly of separate products.
If we make ZClasses a separate product, does that mean we can get our own mailing list for ZClasses. Maybe a separate web site, wiki, etc?
Maybe the 4 or 5 companies who care about ZClasses can get together and fund the upgrade.
That'd be great.
Accordingly, this rapid evolution of Zope, to make it compatible with Zope 3 drives a lot of us nuts. We would prefer to just see a stable Zope 2, and an incompatible Zope 3.
If you want a stable Zope 2, take Zope 2.8.x and stick with it (and possibly maintain it). Many other Zope users actually want to use more and more of the Zope 3 Component Architecture and some of its features in Zope 2. So, this evolution is happening "by popular demand", not just because we like driving you nuts. Oh, and by the way, we do try to provide backward-compatibility. The ZClass case really is an (unfortunate) exception. I wish I even knew what the problem was with them (and I get the feeling most of this discussion could've been avoided if someone who cared about ZClasses actually looked into them and provided by some useful info, and that that had perhaps happened a bit earlier than, say, more than 9 months after that problem was introduced).
But I get no say in the matter.
Well, you posted your thoughts on this list. That's what the rest of us do as well. So, I don't see how you "get no say".
Open source is good, democratic source would be better.
We write proposals and we often vote on things. You're welcome to give your input at any time. Incidentally, Zope 2.9 has been out for more than 9 months and now you're raising the ZClass issue... This is something that could've been brought up during the 2.9 beta phase. Why should we even bother with beta releases if they don't get tested???