Removing the .Safe modules from vector (was: Haskell Platform proposal: Add the vector package)

[Johan Tibell]

On Fri, Aug 31, 2012 at 5:29 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 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