I think we need to have a much more basic discussion.
IMO deprecation was a reasonable thing to try that hasn't really
worked out well. People find deperecation warnings to be very
annoying and I don't think it's going to be practical to make
backward-concompatable changes when eggs are used. I suggest that
generally, in the future, eggs should not be deprecated but just end-
of-lifed. When we are tempted to make a backward cincompatible to a
package, we should create a new one. Generally, there is little cost
in just leaving old packages around.
Unfortunately, there are two poitentially significant costs in
keeping obsolete eggs:
1. They may break with newer Python versions. :(
2. The may be in the dependencies of other eggs. If they are used
internally, then, of course, the dependent eggs can be rewritten to
use newer non-obsolete eggs. In other cases, like zope.app, the
dependency exists to provide some feature and can't be removed
without introducing a backward-incompatible change to the dependent egg.
Honestly, I'm not sure how to deal with these issues, especially the
later. Maybe for collection eggs like zope.app, we have to accept
deprecation and backward-incompatible changes, at least for a while.
Jim Fulton mailto:[EMAIL PROTECTED] Python
CTO (540) 361-1714
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list