planning for ghc-6.10.1 and hackage

Claus Reinke claus.reinke at
Thu Oct 2 07:13:32 EDT 2008

> We're getting pretty close to a final ghc-6.10.1 release. We would like
> of course for the transition this time to be less painful than last
> time. We all got a lot of flack last time for having no plan in place
> and making everyone change all their .cabal files etc.

Thanks to everyone looking into making the transition less of an event
this time! While you've got everyone's attention: there are beta releases 
(a kind of pre-release-candidate?-) of ghc-6.10.1:

and there will be release candidates, so package authors can actually try 
and check whether their package can depend on base4 or should limit itself 
to base3 (either way, it should still specify exactly the range of versions that 
is known to work), and whether there are other issues.

Two things at least that spring to mind, which authors might want to check: 
- ghc-6.10.1 comes with haddock 2 (are there hickups in the generated docs?)
- ghc-6.10.1 comes with a restructured ghc api (all ghc api clients
    will break; the fixes are likely to be minor, but fixing will be necessary)

> The other problem is that packages currently typically specify an
> optimistic upwardly open range rather than a pessimistic closed range.
> Cabal uses the heuristic of picking the highest version of each package
> that satisfies the version constraints.

One could try to use the Ghc Api to run Ghc in typecheck-only mode,
trying the highest versions of dependencies, as given by Cabal's heuristic,
and suggesting to add upper bounds on any dependencies with which
compilation would give errors but for which lower versions are available
within the erroneously specified ranges.

Being optimistic, if typechecking succeeds, one might want to continue
into compilation without further ado, so one might use Ghc directly, just
watching for type-errors relating to packages with open ranges, so that
Cabal could suggest to add upper bounds and to try again. Not a solution,
but perhaps helpful, until Cabal does its own type-checking of interfaces.


PS. Is there a hackage administration mailing list, to which your message 
    could have been copied to reach all package authors?

More information about the Glasgow-haskell-users mailing list