Hanno Schlichting wrote: [snip interesting analysis] > I'd say that the deprecation system in its current form is well suited > and has worked for the more silent times. It is not suited for covering > the changes of a major new version.
I'm not sure it has worked so well. I've seen code in zope.* packages refer to deprecated code in other zope.* packages for a very very long time. I'd also say that we run into the deprecation system *more* in the wild times, such as when Jim refactored the local component registration system. Is a wholesale moving of a class to another place part of the wild times or the quiet times? I'd argue it's more part of the wild times, as a class is rarely moved by itself - the motivation behind this is to more logically arrange the code in packages, and this is something that will touch more than one package. [snip] > Once such a new major version is out, the deprecation system will be > usable again and can cover the more slow paced evolution that will > follow. It's a good tool, but not appropriate for the task at hand. Given the history of its usage in Zope 3 I have my doubts, but perhaps Plone's experience is different and a model we could follow. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
