Although it will definitely solve all problems, it would help if hackage would automatically send out mails to maintainers of packages which do not compile with specific ghc versions.
I have ran a couple of time into the situation where new GHC releases did nor compile my packages anymore, and I only found out by this being pointed out to me. I do not go over the hackage pages of my packages on a daily basis. The changes I had to make were usually minor, and fixing the problems was easy (except for the case where I had to a add a complicated local type, when let bindings were no longer polymorphic), Doaitse On Feb 10, 2013, at 10:50 , Manuel M T Chakravarty <c...@cse.unsw.edu.au> wrote: > Simon Peyton-Jones <simo...@microsoft.com>: >> If there's a path to having a release strategy as Manuel suggests, and >> having an intermediate release with the new vector primops, type extensions >> and such goodness, then I'm all for it. A lot of these bits are things ill >> start using almost immediately in production / real software, esp if I'm not >> needing to patch every stable library beyond maybe relaxing versioning >> constraints. >> >> Let me suggest once more a possible path, along the lines you suggest >> · For people who value stability: use the Haskell Platform. Ignore >> GHC releases. >> · For people who want as many features as possible: use GHC releases. >> · For people who want to live on the bleeding edge: build HEAD from >> source >> >> The Haskell Platform decides which GHC release to use, advertises that to >> package authors who do whatever updates are needed. HP may perfectly >> sensibly skip an entire release entirely. >> >> In short, I think we already have the situation that you desire. Perhaps we >> just need to market it better? >> >> Or am I mistaken? > > There is one kink: for GHC releases to be *useful* substitutes for the HP for > people who want medium stability, they must not change (expect maybe add to) > the APIs in GHC versions that do not coincide with HP releases. > > Why? If they change APIs, many of the packages on Hackage will not build with > these intermediate GHC releases, which makes them useless for anything, but > testing GHC. > > Otherwise, I am perfectly happy with your suggestion. However, this is not > the status quo. All (major) GHC releases do break critical packages on > Hackage. > > Manuel > > > > -- > You received this message because you are subscribed to the Google Groups > "parallel-haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to parallel-haskell+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
