Stephan Richter <[EMAIL PROTECTED]> writes: >> - We need to decide what a Zope 3 release is (or maybe multiple >> flavors). I favor copying the linux experiences, but have an open >> mind. > > I like the Linux parallel as well. I think it would be nice, if we > treat the Zope 3 name like Debian, and Grok or other frameworks on > top of it like Knoppix or other Debian-derived distributions.
There is danger here. Many in the industry consider Linux to be an absolute disaster - because after you develop an application on one distribution, you can spend months trying to support customers who attempt to run it on other distributions! In the wider Unix world things are even worse. Tools like "autoconf" absorb months and years of developer effort to simply get products to compile everywhere. I will suggest an alternative model: Python. The Zope project should not operate like Linux, but like Python. The magic of Python is that it comes with a Standard Library. I am sure, of course, that it takes the Python developers much more time to come out with each version of Python because they have to keep the Standard Library working; I am sure it is troublesome trying to get all the volunteer maintainers on board when they want the next release to meet its deadline; and it seems obvious that both Python and each Standard Library module could evolve faster on their own, without their releases tied to each other. But what an immense benefit results! The normal Python coder, who stands outside the development of the language itself, needs to only be told "this is Python 2.4", and knows automatically not only which core features the language will have, but, also, what versions of one hundred other packages he will be working with. Hearing "2.5" not only tells you that iterator comprehensions are available, but that "datetime" has finally grown a .strptime class method! Now, it sounds like Zope is about to stop being like Python and start being like the current Wild West of Linux distributions. If I want to write a WebWidget in the future, and want it to work with Grok, and Zope on Wheels, and ZopeSprockets, and whatever other frameworks might come along, then I will be faced with situations like "Well, Grok has already moved up to zope.security 3.7, which means I can use key cards natively! Hmm, but the other frameworks have not upgraded past 3.6; I will have to special-case key-cards for them. On the other hand, Grok stayed with zope.templates 3.5 because they piled so many extensions on top that they didn't get time to redevelop them for 3.6, so I'm going to have to fake push-masking in Grok..." In conclusion (and there's a dozen more arguments I want to make, but I think they're all pretty obvious if you start drawing more analogies like the ones above), I think that breaking Zope into eggs makes about as much sense as shipping Python bare and making users assemble working sets of the Standard Library out of Cheeseshop eggs. While perhaps saving a bit of time for the core developers, and perhaps letting new releases come a bit faster since they are not all linked together in a big release, the result of such a move will be to inflict a terrible cost on the normal developer, who will have to re-invent "autoconf" for Zope in order to have any hope of people using his WebWidget. While I'm being all contrary, I might as well make a whimsical suggestion, a small gedankenexperiment: what if we went beyond the suggestion that I am making here - which is that all "core" Zope 3 eggs continue to be released at the same time with a "big version number" attached, exactly like Python and its Standard Library are - and actually encouraged other tools and frameworks to "join in" and follow the same cycle? What, in other words, if there were some way for the WebWidget author - who, you will recall, wants people using all sorts of Zope-based frameworks to be able to use his product - to package his product such that you got the "right version" for the version of Zope you were using? So that someone who put "webwidget" in their "install_requires" stanza would get the "3.4" version if they were using "Zope 3.4", and "3.5" if their Zope version was "3.5", and so forth? Then, not only would all of the Zope core packages be evolving in lockstep, but third-party tools could voluntarily "follow along" with the release cycle schedule, and be able to guarantee that things kept working smoothly for their users. It would be like having to grab the Python-LDAP that claims to work with the Python version you're working with, but where the selection was made automatically without your having to think about it. -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
