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 - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to