For a while we've been doing one major release per year, and 1-2 minor
releases. We have a big sign at the top of the download page directing
people to the platform. We arrived here after various discussions in
the past - there were always a group of people that wanted stability,
and a roughly equally vocal group of people who wanted the latest bits.
So we settled on one API-breaking change per year as a compromise.
Since then, the number of packages has ballooned, and there's a new
factor in the equation: the cost to the ecosystem of an API-breaking
release of GHC. All that updating of packages collectively costs the
community a lot of time, for little benefit. Lots of package updates
contributes to Cabal Hell. The package updates need to happen before
the platform picks up the GHC release, so that when it goes into the
platform, the packages are ready.
So I think, if anything, there's pressure to have fewer major releases
of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months,
7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too
efficient at making releases!
My feeling is that this pace is too fast. You might argue that with
better tools and infrastructure the community wouldn't have so much work
to do for each release, and I wholeheartedly agree. Perhaps if we stop
releasing GHC so frequently they'll have time to work on it :)
Releasing early and often is great, but at the moment it's having
negative effects on the ecosystem (arguably due to deficiencies in the
infrastructure).
Does this strike a chord with anyone, or have I got the wrong impression
and everyone is happy with the pace?
Cheers,
Simon
On 07/02/13 18:15, Simon Peyton-Jones wrote:
It’s fairly simple in my mind. There are two “channels” (if I
understand Mark’s terminology right):
·Haskell Platform:
oA stable development environment, lots of libraries known to work
oNewcomers, and people who value stability, should use the Haskell
Platform
oHP comes with a particular version of GHC, probably not the hottest
new one, but that doesn’t matter. It works.
·GHC home page downloads:
oMore features but not so stable
oLibraries not guaranteed to work
oWorth releasing, though, as a forcing function to fix bugs, and as a
checkpoint for people to test, so that by the time the HP adopts a
particular version it is reasonably solid.
So we already have the two channels Mark asks for, don’t we? One is
called the Haskell Platform and one is called the GHC home page.
That leaves a PR issue: we really /don’t/ want newcomers or Joe Users
wanting the “new shiny”. They want the Haskell Platform, and as Mark
says those users should not pay the slightest attention until it
appears in the Haskell Platform.
So perhaps we principally need a way to point people away from GHC and
towards HP? eg We could prominently say at every download point
“Stop! Are you sure you want this? You might be better off with the
Haskell Platform! Here’s why...”.
Have I understood aright? If so, how could we achieve the right
social dynamics?
Our goal is to let people who value stability get stability, while the
hot-shots race along in a different channel and pay the price of flat
tires etc.
PS: absolutely right to use 7.6.2 for the next HP. Don’t even think
about 7.8.
Simon
*From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com]
*Sent:* 07 February 2013 17:43
*To:* Simon Peyton-Jones
*Cc:* andreas.voel...@gmail.com; Carter Schonwald; GHC users; Simon
Marlow; parallel-haskell; kosti...@gmail.com; Edsko de Vries;
ghc-d...@haskell.org
*Subject:* Re: GHC 7.8 release?
I'd say the window for 7.8 in the platform is about closed. If 7.8
were to be release in the next two weeks that would be just about the
least amount of time I'd want to see for libraries in the platform to
get all stable with the GHC version. And we'd also be counting on the
GHC team to be quickly responding to bugs so that there could be a
point release of 7.8 mid-April. Historically, none of that seems likely.
So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2.
Since 7.8 will seems like it will be released before May, we will be
faced again with the bad public relations issue: Everyone will want
the new shiny and be confused as to why the platform is such a
laggard. We'll see four reactions:
* New comers who are starting out and figure they should use the
latest... Many will try to use 7.8, half the libraries on hackage
won't work, things will be wonky, and they'll have a poor experience.
* People doing production / project work will stay on 7.6 and ignore
7.8 for a few months.
* The small group of people exploring the frontiers will know how to
get things set up and be happy.
* Eventually library authors will get around to making sure their
stuff will work with it.
I wish GHC would radically change it's release process. Things like
7.8 shouldn't be release as "7.8". That sounds major and stable. The
web site will have 7.8 at the top. The warning to use
the platform will fall flat because it makes the platform look out of
date. Really, "7.8" should be in a different release channel, not on
the front page. It should bake in that channel for six months - where
only the third group of people will use it, until it is getting close
to merge into main, at which point the fourth group will start to use
it, so that the day it hits main, all the libraries just work.
Ideally, the first two groups of people will not pay the slightest
attention to it until it is further baked.
While we achievements of the GHC team are great, less than half of
those 7.8 features seem interesting from the viewpoint of the aims of
the platform. I don't think adding syntactic or type-level features
are really all that important for Haskell at this juncture. And while
I do like to see improvements in generated code and run-time
performance, I think even those are less important than making crucial
ecosystem improvements to things like package management,
cross-compilation, and libraries.
- Mark
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
