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

Reply via email to