

Simon Marlow simonmarhaskell at gmail.com
Mon Oct 15 05:53:25 EDT 2007

Claus Reinke wrote:

> but calling "split-base" "base" goes directly against all basic 
> assumptions of all packages depending on "base".

The new base will have a new version number.  There is no expectation of 
compatibility when the major version is bumped; but we do have an informal 
convention that minor version bumps only add functionality, and sub-minor 
version bumps don't change the API at all.

So a package that depends on 'base' (with no upper version bound) *might* 
be broken in GHC 6.8.1, depending on which modules from base it actually 
uses.  Let's look at the other options:

   - if we rename base, the package will *definitely* be broken

   - if the package specified an upper bound on its base dependency, it will
     *definitely* be broken

In the design we've chosen, some packages continue to work without change.

Specifying a dependency on a package without giving an explicit version 
range is a bet: sometimes it wins, sometimes it doesn't.  The nice thing is 
that we have most of our packages in one place, so we can easily test which 
ones are broken and notify the maintainers and/or fix them.

Another reason not to change the name of 'base' is that there would be a 
significant cost to doing so: the name is everywhere, not just in the 
source code of GHC and its tools, but wiki pages, documentation, and so on. 
  Yes I know we've changed other names - very little in packaging is clear-cut.


More information about the Haskell-Cafe mailing list