GHC 7.8 release?

[Carter Schonwald]

+10^100 to Johan and Manuel. Breaking changes on pieces that aren't
experimental is the main compatibility / new version pain,

and I say this as someone who's spent time before and around the 7.4 and
7.6 releases testing out lots of major packages and sending a few patches
to various maintainers.

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.

-Carter
On Feb 8, 2013 9:05 PM, "Manuel M T Chakravarty" <chak at cse.unsw.edu.au>
wrote:

> I completely agree with Johan. The problem is to change core APIs too
> fast. Adding, say, SIMD instructions or having a new type extension (that
> needs to be explicitly activated with a -X option) shouldn't break packages.
>
> I'm all for restricting major API changes to once a year, but why can't we
> have multiple updates to the code generator per year or generally release
> that don't affect a large number of packages on Hackage?
>
> Manuel
>
> Johan Tibell <johan.tibell at gmail.com>:
>
> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>>  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!
>>
>
> I think we want to decouple GHC "major" releases (as in, we did lots of
> work) from API breaking releases. For example, GCC has lots of major (or
> "big") releases, but rarely, if ever, break programs.
>
> I'd be delighted to see a release once in a while that made my programs
> faster/smaller/buggy without breaking any of them.
>
> -- Johan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/49dfc45b/attachment.htm>