On 5 July 2011 11:26, Tobias Helfrich
<Helfrich@know-it.net> wrote:
Hi Hanno
> On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich
> <
Helfrich@know-it.net> wrote:
> > OK, so you do think that we might use Zope 2.12 for a quite
> long time
> > without thinking about anymore updates? Will there be any security
> > updates for Zope 2.12 in the future?
>
> You want to use Zope 2.13. 2.12 is at the end of its active
> maintenance cycle as is Python 2.6 (the only Python version
> it supports).
>
> Zope 2.13 brings support for Python 2.7, which is a long-term
> maintenance release.
techniques mentioned before? That will give us another two years to
think about going on with different styles. So basically Zope 2 will
be the framework for Plone only, because the community which is/was
using Zope 2 for standalone individual projects has decreased to nearly
none.
I think it would be very sad if that happened, especially since there evidently demand from other projects.
What I think is clear is that to evolve Zope 2, we need to shed some baggage and make some deeper changes to allow us to achieve some of our goals (e.g. WSGI, simplified stack, simpler and more easily controllable security, less magical traversal, more comprehensible publisher).
Plone is obviously a big consumer of Zope 2 and I would expect Plone to have a major influence on Zope 2's evolution. But ERP5 is another big consumer, and we shouldn't ignore that.
So it might be a good idea to look for something completely
different? I don't think that Plone will be able to do everything we
want it to. Or do you think we can stick with Zope 2 but change the way
of building applications to ZPT/TAL? So we have to get rid of all DTML
and what about an alternative to the ZSQL Methods?
I think keeping DTML as an optional installation should be quite feasible. It's just possibly not something that the core Zope 2 team want to maintain anymore in the standard distribution.
ZSQL Methods may be a similar story, in fact, especially as they rely on DTML. However, I'd encourage you to look at SQLAlchemy, which is way nicer to work with.
OK, i have subscribed to the mailing list today, so unfortunately
i haven't found this sort of information anywhere else. I don't want
to blame you or anyone else for that, but it's not nice to hear that
right now :-(
I think there is some characteristic bluntness in Hanno's emails, but please realise that none of this is going to happen over night, and existing codebases are not going to magically disappear. Sometimes we have to be a bit more radical to understand the art of the possible and build a future platform that will support future needs. That doesn't mean there can't be both migration paths and long-term stable versions.
Martin