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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to