[Haskell-cafe] Stackage with GHC 7.8 has started

[Michael Snoyman]

On Sat, Oct 19, 2013 at 9:31 AM, Ketil Malde <ketil at malde.org> wrote:

>
> Michael Snoyman <michael at snoyman.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131019/1b12a882/attachment.html>