Re: [Haskell-cafe] Stackage with GHC 7.8 has started

On Sat, Oct 19, 2013 at 9:31 AM, Ketil Malde wrote:

Michael Snoyman writes:

...

* If you have a package with a restrictive upper bound, now's a good time to start testing that package with GHC 7.8 and relaxing those upper bounds. It would be great if, when GHC 7.8 is released, a large percentage of Hackage already compiled with it.

The biggest problem with upper bounds (or not), is that frequently, somebody will update a package that requires a bleeding edge GHC. I, on the other hand, often need to install software on older systems (last time was Fedora 17, more than a year old, and shipping GHC 7.0.4). Needless to say, central packages like template-haskell, array, stringable, and happy all fail to compile, and then I try to manually install older and older versions of these packages, until one of them finally works. This is time consuming and cumbersome, and while I can do it, I clearly cannot inflict this on my users.

(And some systems I have to work with - typically "enterprise" distributions - ship with even older GHC versions, but then I typically compile GHC from source.)

IIUC, what you're pointing out isn't really about upper bounds, but about the lack of backwards compatibility with GHC core packages. I couldn't agree more with this sentiment. I highly encourage maintainers to use Cabal CPP macros to ensure that their code compiles with the widest range of dependencies, *especially* core packages. containers is probably the biggest problem here, where I've many times seen some code import Data.Map.Strict and thereby exclude older versions of containers, when a simple CPP macro would have fixed the problem.

...

* If you have a package on Hackage that is not yet on Stackage, now's a great time to add it.

I'd love to, what do I need to do?

There's a maintainer's agreement available at: https://github.com/fpco/stackage/wiki/Maintainers-Agreement I'm considering making a simplifying modification to this agreement: if you want to include a package, but haven't tested it against Stackage, feel free to just send me a pull request with the addition, and just make sure to comment that you haven't tested it yet. I don't mind being your first line of compatibility checking here, as I know that running a full Stackage build can be a time-consuming process.

...

We're going to be doing daily builds against three versions of GHC (7.4.2, 7.6.3, and 7.8), which will help ensure your packages continue to build consistently.

This is great, any chance of including yet older compilers? The sad fact of life is that people use "enterprise" and "LTS" distributions, which inevitably means outdated software..

Unfortunately, it's doubtful. I'm hopeful that moving forward, Stackage can encourage maintainers to continue supporting GHC 7.4.2 for longer than previous GHC releases have been supported. But I doubt there will be enough momentum to convince most package maintainers to start adding support for GHC 7.0 or 7.2, both of which are over two years old. I'd love to see a GHC version supported for more than two years, but it's very difficult to add those fixes in after the fact. Nonetheless, I'm downloading GHC 7.0.4 right now, I'll see if I can try to get a build going, but if my intuition is correct, the number of failures will be too high to even attempt addressing them. Michael