
On Fri, Aug 31, 2012 at 5:29 AM, Simon Marlow
Why not a deprecation pragma initially? That's like adding another level of "soft deprecation"; how long before we also need "extra-soft deprecation" and "ultra-soft deprecation"? (I feel a bog-roll analogy coming on :-)
Because libraries need to support not only the last release of vector but also a few versions back. The reason is the following: If * Package P1 depends on package P2 <= A.B.C and P3 <= X.Y.Z. * Package P2 depends on package P3 <= X.Y.Z. * A new major release of package P3, X.Y.Z+1, that moves some functions to a new module and leaves behind deprecated re-exports, is released. * A new release of P2, A.B.C+1, that adds some new functions (unrelated to the changes in P3) is made. This release uses the new P3 API in order to get rid of deprecation messages, and thus have to depend on P3 == X.Y.Z+1. * P1 wants to use the new P2 API and thus depends on P2 == A.B.C+1. * P1 no longer builds due to its dependency chain contains incompatible constraints on P3. We've seen this on Hackage in the past. Introducing lower bounds on the latest release of a package creates a "but" through Hackage between packages that has an upper bound that excludes the new release and packages that have a lower bound that includes it. Breakage ensues. This last happened with the deepseq package I think. Authors can work around the problem with CPP, but it's ugly and annoying. My preference is to have a soft deprecation (i.e. comments) of an API, wait for a period of time, add pragmas to catch the last non-updaters, make the braking change. -- Johan