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 - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
