wither the Platform

[Mark Lentczner]

On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones <simonpj at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150325/032ed65b/attachment.html>