cabal release (was: cabal experiences)

Duncan Coutts duncan.coutts at
Mon Dec 12 10:14:09 EST 2005

On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
> If the reason you want 6.6 is to get a new Cabal, why not download a
> new Cabal package?  Or is there another reason you want 6.6?

That is exactly the problem. All non-trivial packages need a later
version of Cabal since there are many many minor bug fixes and little
feature additions in later versions of Cabal.

So it's fine for package developers to download a later Cabal version
but the sense some people have is that they can't ask their users to
upgrade their Cabal installation from the one that comes with GHC.
> Bug-fixes to 6.4 are a much smaller deal. 

The improvements are a mixture of bug fixes and feature additions and
some api changes. So because of the policy for minor versions of GHC is
to not change any apis including those of Cabal, GHC 6.4.1 came with a
version of Cabal that is widely acknowledged to be buggy and unsuitable
for many packages and distributors. We can sometimes persuade users to
upgrade their Cabal package separately from their GHC installation, but
not always.

In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. That is
after installing GHC 6.4.1 we unregister Cabal-1.0 and install
Cabal-1.1.3. We do not allow any choice in that. This was necessary
because our build/distribution infrastructure could not work around the
bugs in Cabal-1.0 and besides many packages that we want to distribute
require later versions of Cabal. So Gentoo users are ok, but other users
are not.

So this is why there is pressure in some quarters for a major release,
(6.6) rather than another minor release (6.4.2) since the former would
allow package authors to support a released version of GHC because it
would come with a usable version of Cabal. A minor release with the same
Cabal-1.0 would leave people in the same situation as now.

I appreciate that we do not want to rush the next major release because
there are new features that need to be got right. Perhaps we should
think again about which Cabal version to include in the next GHC minor
version, or perhaps to advise users in the release notes for GHC 6.4.2
that it is highly recommended to upgrade to Cabal version x.y.

Perhaps another compromise would be for GHC 6.4.2 to ship more than one
version of Cabal. It could ship version 1.0 and have that exposed by
default so that GHC's api stability guarantees could be met and it could
also ship a more recent version that we can agree upon so that it would
be much less difficult for the average user to build packages that
require more recent Cabal versions.


More information about the Libraries mailing list