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@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan | Coutts | Sent: 12 December 2005 15:14 | To: Simon Peyton-Jones | Cc: libraries@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@haskell.org | http://www.haskell.org/mailman/listinfo/libraries