Re: Zope 3 releases?

Jim Fulton wrote:
> On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote:
[snip]
>>> - We need a *realistic* (especially wrt available resources) process
>>> for managing releases.  There are 2 aspects of this.  We shouldn't
>>> make plans for which there aren't enough resources.  We also
>>> shouldn't plan significant tasks that people won't care enough to
>>> work on.  I think the classic Zope 3.4 release is a good example of a
>>> large effort that really wouldn't benefit many people, if any.
>>
>> Do you have a sort explanation on what is the missing resource? Is it,
>> as it was for 3.3, lack of people-hours with knowledge in fixing the
>> last bugs?
> 
> I'm not entirely sure.  I just observe that this doesn't seem to be 
> making much progress.

I think it's one of the drawbacks of taking an ecosystem/libraries 
approach instead of a application/framework style approach. An 
application or framework typically is an integrated whole that has a 
single version number. An ecosystem or set of libraries can be 
integrated (which Zope 3 is) but everything evolves at different rates 
and there's no single thing to install or talk about.

I'm not saying an ecosystem approach is bad, if that's what Zope 3 wants 
to be. I do think that such an approach needs to be supplemented by a 
framework approach (and I've been putting work into one way to do that).

If Zope 3 is an ecosystem, a "release" of Zope 3 the ecosystem doesn't 
really make much sense. To follow the comparison with Linux 
distribution, it's more like a "distribution" of an ecosystem. I'd 
therefore suggest that the release of Zope 3.4, if it ever actually 
happens, will be the last release of Zope 3 the application server 
framework.

I hope that besides Grok, some community will stand up that takes a less 
radical approach to building an application server on top of the Zope 3 
ecosystem. People having existing applications in Zope 3 to maintain 
(like myself with the Document Library) will have a need for it, and 
Grok doesn't suit everyone's tastes anyway, especially people 
comfortable with existing Zope 3 practices. As I said elsewhere, I 
suggest we call this project not "Zope 3" but something else, to avoid 
confusion with the Zope ecosystem (and also to avoid implying it's the 
clear successor to Zope 2. I think we can safely say by now that's not 
how history went).

Regards,

Martijn