cabal release (was: cabal experiences)

[Simon Peyton-Jones]

Why is it easier to get users to upgrade from GHC 6.4.1 to GHC 6.6 than
it is to upgrade from Cabal 1.0 to Cabal 1.7 (say)?  I must be missing
something.

S

| -----Original Message-----
| From: libraries-bounces at haskell.org
[mailto:libraries-bounces at haskell.org] On Behalf Of Duncan
| Coutts
| Sent: 12 December 2005 15:14
| To: Simon Peyton-Jones
| Cc: libraries at haskell.org; Isaac Jones
| Subject: RE: cabal release (was: cabal experiences)
| 
| 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.
| 
| Duncan
| 
| _______________________________________________
| Libraries mailing list
| Libraries at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries