[Zope3-dev] Re: Zope 3 releases?

[Brandon Craig Rhodes]

Stephan Richter <srichter at cosmos.phy.tufts.edu> 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   brandon at rhodesmill.org   http://rhodesmill.org/brandon