Tres Seaver wrote:
> I take cleaning up deprecation warnings seriously:  I want all tests for
> my packages, for instance, to run without emitting *any* of them.
> Deprecation warnings have a non-trivial downside:  consider the case
> wher  one of *my* downstream users updates Roger's pacakge (e.g., to
> pick up a critcial security fix, or something).  My package has
> dependencies which allow this (because I don't put hard pins in library
> packages), but now *my* package now emits warnings, where it didn't before.

You should, and likely are, shipping your package with a recommended 
list of versions. If your user upgrades beyond that recommended list of 
versions, then that user knows that any problems that may occur are his 
own responsibility. A deprecation warning is hardly a disastrous thing 
to swallow if you're fixing a security bug.

I'd also argue that deprecation warnings and security bug fixes should 
generally not be introduced in the same release, as deprecation should 
be considered to be a feature change.

Anyway, the problem of your downstream users is worse. If you depend on 
x.y, and Roger makes it so that x.y doesn't depend on a.b anymore, and 
your downstream user updates to Roger's version of x.y, they will 
suddenly have breaking *imports* as they happened to be relying on 
things in a.b which just happened to get pulled in too.

> If we just leave the name importable from the old location, what is
> hurt?  The major downside is that people won't learn about the new
> location.

Yes, the hurt is that we aren't actually signalling the deprecation of 
the old location. If the goal is to reduce the dependencies between 
packages, it's pretty nice if people can follow this in their own 
packages so that *they* can benefit from less useless dependencies being 
pulled in as well.

>  I consider this to be less an issue than the two problems I
> outline above.  Even if the "pending warning" bit works, I still have to
> add the BBB cruft to my code to future-proof it.

Why? Your downstream users won't see any warnings.



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