On Sunday 17 April 2011, Tres Seaver wrote:
> Moving a "big old application" across multiple major versions at onece
> of any platform is likely to be painful: even projects which are
> careful about backward compatibility (Zope has historically been very
> good at this) will have issued deprecation warnings in the versions you
> skip. Your best bet would be to port the app stepwise to the latest
> release of each major version, noting and fixing the warnings as you go.
> Zope 2.12 - 2.13 is likely to be the biggest jump, because 2.13
> includes lots of changes which *remove* functionality from Zope to
> optional add-ons.
I do agree with this and I have been keeping my apps current so they run on
zope 2.13 and overall this has not been a huge burden. The problem is that
with this change the feature used is deprecated but the replacement is not
really documented anywhere so how to upgrade is not remotely clear.
Zope does need to change and grow and so long as I can keep it a viable
platform for what I do I will probably stay on it since it just works so
amazingly well. I would just like documentation for the new systems that
replace deprecated features. How is someone supposed to write a new app that
uses the new event system without docs for it? If nobody is going to use the
new event system what is the point of it?
I have spent some time looking at other frameworks and most just don't look
very promising to me. For grok my biggiest issue was fail open. It looks like
the default is allow everything unless explicitely denied and I feel that is
just a recipe for disaster. Pyramid looks pretty good and it does have a
security system that you can set to fail closed but still I have a massive
investment in zope 2.x and I don't want to just throw that away for nothing.
We still manage to massively outdo our competitors using much newer technology
in time to get a solution done, in cost and in reliability.
So I would just like to see zope 2.x remain a viable platform and if things
are to be removed or deprecated the replacement systems need some level of
docs. Idealy, if I could, I would make it so that varous manage_before* and
manage_after* type events would just call the zope.lifecycle stuff as a
compatibility layer so all the old code would go away but old apps would work
and the code itself would serve as instructions on how to upgrade.
That way CatalogPathAwareness would stay but basically just be a wrapper for
zope.lifecycle if that is possible.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -