Martijn Faassen wrote:
>>> I will also note that just because Zope 2 won't die, it doesn't mean we
>>> shouldn't clean it up. Eventually, Zope should mostly be reusing things
>>> from Zed.
>> +sys.maxint
>> I think this will be the way we get a real forward migration path for an
>> awful lot of us who are still using Zope 2 today, and expect to continue
>> doing so.
>> We may or may not ever port to "zope 3", whatever that will mean in the
>> future. More likely we will just incrementally improve and clean up our
>> applications, just as Zope 2 itself will be getting incrementally better
>> and cleaner.  We'll have to address deprecation warnings at each
>> upgrade, but at no point will we be forced to do a complete rewrite.
>> And along the way, we'll be gradually getting access to more and more
>> nifty features.
> I don't see how we need a new vision. This has been the vision
> (evolution, not revolution) that I've been carrying out with Five for
> the last few years and thanks to a lot of contributions by a large range
> of developers, we've been making it work. Can't we just keep going on
> the way we've been going then?

In many ways, that's precisely the idea. However, I agree with Jim when
he says that we currently have a Zope 2 wanting to become like Zope 3
and a Zope 3 wanting to get all that what Zope 2 has. That'll leave us
with two Zopes for a while.

Zope 3 is "exploding" into several bits and pieces. That is good. The
question is whether one of those (larger) pieces will also be an app
server or whether one app server that evolves just the way we've been
evolving it since Zope 2.8 is enough.

I think focusing on one app server and a dedicated set of libraries
would be a good alternative to two concurring app servers.

Zope3-dev mailing list

Reply via email to