[Zope3-dev] Re: Eggs for deprecated packages

[Martin Aspeli]

Jim Fulton wrote:
> 
> 
> 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.
> 

Are you talking only about whole eggs here, or also about changes to APIs
within eggs that are deemed to have a right to exist?

Deprecation of APIs within a package works reasonably well as we do it now,
imho. If you look at other systems, e.g. the Java APIs, deprecations tend to
take place, though often deprecated APIs are never removed (which has the
downside that they continue to clutter the namespace and sometimes they
could be harmful by design). Deprecation warnings are important here,
because it gives people a fighting chance of forward migrating their code.
Without warnings, we'll have a lot of people that simply get locked into a
version, and find that two or three versions down the line an upgrade would
really mean a rewrite.

Deprecation of entire eggs (e.g. we don't need it anymore, or we think it
needs to move to a different namespace, or we want to break it up into
smaller pieces or amalgamate with some other pieces to make a bigger
package) is kind of a non-issue as far as eggs are concerned. Eggs are
versioned, and people can always depend on specific "old" eggs even if
they're not actively maintained or ship as part of the main Zope 3
distribution.

As far as "the system" is concerned (whatever you want to call the system,
but let's say that we mean the collection of eggs that we ship as Zope 3 and
promote as a cohesive platform for people to develop on top of) I think we
still need some type of deprecation when we decide to stop packaging up
particular eggs. Say someone is used to downloading and using the standard
Zope 3 distribution (or a particular distribution) - they will assume that
all those packages remain there. When they upgrade, they don't want to
suddenly find that something's gone missing. That's where I suggest we have
a "deprecated-in-version-x" meta-egg that someone can depend on if they need
to get particular packages that no longer exist in the form they used to. It
can ship with Zope 3, ship disabled, or not ship but be documented as the
way to get back the things that were moved, so that developers can
understand the implications of package removals/end-of-life on their own
code and have time to take action accordingly.

Martin
-- 
View this message in context: http://www.nabble.com/Eggs-for-deprecated-packages-tf3485561.html#a9751811
Sent from the Zope3 - dev mailing list archive at Nabble.com.