Changes between Version 1 and Version 2 of Commentary/Packages/PackageCompatibilityProposal


Ignore:
Timestamp:
Oct 24, 2007 2:16:51 PM (7 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Packages/PackageCompatibilityProposal

    v1 v2  
    33In GHC 6.8.1 we reorganised some of the contents of the packages we ship with GHC, see #710.  The idea was to lessen the problem caused by the base package being essentially static between GHC major releases.  By separating modules out of base and putting them into separate packages, it is possible to updgrade these modules independently of GHC. 
    44 
    5 The reorganisations unfortunately exposed some problems with our package infrastructure, in particular most packages that compiled with 6.6 do not compile with 6.8.1 because they don't depend on the new packages.  We anticipated the problem to some extent, adding "configurations" to Cabal to make it possible to write conditional package specifications that work with multiple sets of dependencies.  We are still left with the problem that the `.cabal` files for all packages need to be updated for GHC 6.8.1.  This seems like the wrong way around: the change we made to a few packages has to be propagated everywhere, when there should be a way to confine it locally, at least for the purposes of continued compatibility with existing source code.  In many cases, the underlying APIs are still available, just from a different place.  (in general this may not be true - modifications to packages may make changes to APIs which require real changes to dependent packages). 
     5The reorganisations unfortunately exposed some problems with our package infrastructure, in particular most packages that compiled with 6.6 do not compile with 6.8.1 because they don't depend on the new packages.  Some instructions for upgrading packages are here: [http://haskell.org/haskellwiki/Upgrading_packages Upgrading packages]. 
     6 
     7We anticipated the problem to some extent, adding "configurations" to Cabal to make it possible to write conditional package specifications that work with multiple sets of dependencies.  We are still left with the problem that the `.cabal` files for all packages need to be updated for GHC 6.8.1.  This seems like the wrong way around: the change we made to a few packages has to be propagated everywhere, when there should be a way to confine it locally, at least for the purposes of continued compatibility with existing source code.  In many cases, the underlying APIs are still available, just from a different place.  (in general this may not be true - modifications to packages may make changes to APIs which require real changes to dependent packages). 
    68 
    79Some of the problems that contributed to this situation can be addressed.  We wrote the [http://haskell.org/haskellwiki/Package_versioning_policy Package Versioning Policy] so that packages can start using versions that reflect API changes, and so that dependencies can start being precise about which dependencies they work with. If we follow these guidelines, then