On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones <simonpj@microsoft.com> wrote:

Yes!  Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ...


I still like that plan!

Concrete proposal based on that and the other fine input in the responses:

Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC!

Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day.

Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation.

Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install.

One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there.


This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time!

Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... 

I think we can do this if all the great volunteer talent in our community steps up. Shall we?

— Mark