Breakage with 6.10

[Duncan Coutts]

On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote:
> arrows fails due to:
> 
>     [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o )
> 
>     Control/Arrow/Transformer/CoState.hs:24:29:
>         Module `Control.Arrow' does not export `pure'
> 
> Even though cabal-install decided to use base-3.0.3.0
> 
> So that means base-3 is *not* exporting quite the same interface as last time.
> Were we aware of this?

Note that this means that base-3 should have the version number 3.1.x.y
because there is at least one incompatible api change. We're promoting
the versioning policy so we need to follow it ourselves in our base
libs.

On this issue, we've discussed before that packages should be able to
opt-into the versioning policy and that if they do we can have our tools
suggest that dependencies on such packages should take a particular
form. For example depending on and api version ==1.1.* and not upward
open ranges, or mistakes like parsec <= 2.1.0.0.

There's not time to implement these suggestions in the tools for 6.10
however we do have the opportunity to annotate the packages that we
believe do follow the versioning policy. We can then get our tools make
use of this information in the coming months.

So my suggestion is that in time for 6.10.1 we add something like the
following to the .cabal files for all the core and extra packages:

x-follows-version-policy:

This is free. It doesn't involve any api changes in Cabal or anything
else. All such "x-" extension fields are allowed by cabal and collected
into a name/value pair list. If it seems to work out then we can make it
a proper field (and at that time we can argue what colour we should
paint it).

Sound sensible? We can send patches to add this to the core + extra
packages.

I think it'd be good to do this now because while the base 3 - 4 thing
has gone fairly well this time, future changes would be much easier if
we were using more sensible dependency constraints. I think the best way
to communicate that to developers is through warnings generated by their
tools.

Yes that's right, cabal-install is a channel for package QA propaganda.

Duncan