Changes to GHC that will expose new packages

[Ian Lynagh]

On Sat, Mar 24, 2012 at 09:30:04AM +0000, Ross Paterson wrote:
> On Thu, Mar 22, 2012 at 07:12:41PM +0000, Ian Lynagh wrote:
> > On Thu, Mar 22, 2012 at 06:10:49PM +0000, Ross Paterson wrote:
> > > GHC is still using an old version of mtl.
> > 
> > Oh; as far as http://hackage.haskell.org/trac/ghc/wiki/Repositories
> > knows, we're the upstream for mtl. What should we be using?
> 
> Shouldn't you be using upstream releases rather than the source
> repositories?

That has advantages and disadvantages.

Advantages:
* It's physically impossible to release with libraries that don't match
  upstream
* You can't accidentally make changes to your own checkout of the
  libraries

Disadvantages:
* When changes in GHC, base etc require changes to libraries it's harder
  to test them
* When changes in GHC, base etc require changes to libraries, the
  library upstreams have to not only make the changes but also make a
  release before the GHC/base/... change can be made
* When such a change in one library requires a major version bump, you
  also need a release of any libraries that depend on it too.

> (You do that for the time package, I think.)

We do.

> Otherwise
> GHC releases will be releasing new versions of upstream packages.

Right. We also have the problem that GHC 7.4.1 might release with
somelib 1.0, upstream go on to make lots of changes and release somelib
2.0, and then for GHC 7.4.2 to need a bugfix to the library. Then
someone (either upstream or the GHC team) will need to make a 1.0.0.1
bugfix release.

Here's what I proposed to the library maintainers for the 7.4 branch:

    So I think that the best solution is for GHC's HEAD (i.e. git
    "master" branch) to continue to faithfully track upstreams, while on
    stable branches (e.g. git "ghc-7.4" branch) we make GHC-specific
    changes to version numbers and dependencies, and pull bug fixes as
    appropriate. For libraries that come pre-installed with GHC we will
    also need to make corresponding uploads to hackage, so I will try to
    liase with the maintainers to choose the best version numbers.


Thanks
Ian