Simon Peyton-Jones <simo...@microsoft.com>: > | > You may ask what use is a GHC release that doesn't cause a wave of > updates? > | And hence that doesn't work with at least some libraries. Well, it's a > very useful > | forcing function to get new features actually out and tested. > | > | But the way you test new features is to write programs that use them, > | and programs depend on libraries. > > That is of course ideal, but the ideal carries costs. A half way house is a > release whose library support will be patchy. Not such good testing, but > much lower costs. But still (I think) a lot more testing than "compile HEAD" > gives us.
I don't think so. In my experience, library support is not patchy, but virtually non-existent as some of the very widely used libraries (like Text) break, and everything else depends on them in one way or another. If we don't make sure that the commonly used libraries work with these "preview" releases, I don't think those releases are worth the effort. I understand that we can't really guarantee API backwards compatibility for the GHC API (but that's ok as few packages depend on that). Critical are all the libraries bundled with GHC. Adding to them is fine, but no API definitions should change or be removed. Manuel _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
