johan.tibell:
In general, I think it would be a good idea to provide some statistics of how many packages would break as the result of a backwards incompatible change. Without that data I find it hard to do a cost-benefit analysis. So I hereby suggest that we make a recompile of Hackage a requirement for any breaking language changes. I understand that it might not be that easy to recompile all of Hackage at the moment so we should try to come up with some step-by-step instructions on how to do it. In the future it would be nice to have a little script that does it and spits out some statistics.
Agreed. And it should be required as part of release processes for GHC. Duncan has described the process of building large amounts of Hackage, http://blog.well-typed.com/2009/03/regression-testing-with-hackage/ We used this prior to the ghc 6.10 release to find a few interesting type system bugs, and get in steps for what breaks and why, ultimately easing the upgrade process so that it affected only a couple of percent of packages. So, +1, let's take advantage of this centralization to improve overall quality standards. -- Don