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.
> 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -