Good plan.  You didn’t mention a key point:

·         Make sure that installing the Platform doesn’t get in the way, if you 
subsequently want to upgrade libraries or whatever.

I am un-clear about precisely what the problem(s) is/are here.  I’m pretty sure 
they require infrastructure work (in Cabal) to achieve.

Simon

From: Mark Lentczner [mailto:mark.lentcz...@gmail.com]
Sent: 25 March 2015 14:25
To: Simon Peyton Jones
Cc: Gershom B; Manuel M T Chakravarty; haskell-platform@projects.haskell.org; 
haskell-infrastruct...@community.galois.com; Duncan Coutts; 
ghc-d...@haskell.org; Haskell Libraries
Subject: Re: wither the Platform

On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones 
<simo...@microsoft.com<mailto:simo...@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

_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform

Reply via email to