Michael Snoyman
* 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.)
* 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?
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.. -k -- If I haven't seen further, it is by standing in the footprints of giants