Geoff's reasoning seems quite sound. +1 for February release. On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland wrote:

In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release.

Geoff

On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote:

...

Dear GHC users,

* *

*Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish?

*Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8.

Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think.

At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically:

· major improvements in DPH (vectorisation avoidance, new vectoriser)

· type holes

· rebindable list syntax

· major changes to the type inference engine

· type level natural numbers

· overlapping type families

· the new code generator

· support for vector (SSE/AVX) instructions

Whenever it comes it would definitely be great to include Andreas & friends’ work:

· Scheduler changes to the RTS to improve latency

The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.)

So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4.

There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know.

Simon

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

I agree with Ian. Mid-February is very soon, and there's a lot of stuff that seems to just be coming in now. That doesn't leave much time for testing to get 7.8 out in sync with the platform. Although my perspective is a bit colored by the last release. Testing the 7.6.1 RC took several weeks for us because of the number of upstream packages that needed to be updated (not all trivially). By the time we were prepared to begin testing our own systems 7.6.1 was already released, and we couldn't use it because of a number of bugs ( http://hackage.haskell.org/trac/ghc/ticket/7257 was a blocker, but there were others also). Most of the bugs were fixed very quickly (thanks Simon M. and Simon PJ!), but by then they were already in the wild. If there had been a bit more time to test 7.6.1, maybe some of those fixes would have made it into the release. John L. On Thu, Feb 7, 2013 at 10:23 PM, Ian Lynagh wrote:

I'm not too optimistic we could actually get the final release out during February, assuming we want to allow a couple of weeks for people to test an RC.

Does the Haskell Platform actually want to commit to using a GHC release with "tons of [new] stuff", that has had little testing, days or weeks after its release? I thought the idea was that it would favour known-good releases over the latest-and-greatest, but perhaps I misunderstood or the philosophy has changed.

Thanks Ian

...

Geoff's reasoning seems quite sound. +1 for February release.

On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland wrote:

...

In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release.

Geoff

On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote:

...

Dear GHC users,

* *

*Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish?

*Andreas*: We are almost there - we are now trying to sort out a

On Thu, Feb 07, 2013 at 09:00:37AM -0500, Richard Eisenberg wrote: problem

...

...

...

on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8.

Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think.

At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically:

· major improvements in DPH (vectorisation avoidance, new vectoriser)

· type holes

· rebindable list syntax

· major changes to the type inference engine

· type level natural numbers

· overlapping type families

· the new code generator

· support for vector (SSE/AVX) instructions

Whenever it comes it would definitely be great to include Andreas & friends’ work:

· Scheduler changes to the RTS to improve latency

The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.)

So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4.

There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know.

Simon

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

It’s fairly simple in my mind. There are two “channels” (if I understand Mark’s terminology right): · Haskell Platform: o A stable development environment, lots of libraries known to work o Newcomers, and people who value stability, should use the Haskell Platform o HP comes with a particular version of GHC, probably not the hottest new one, but that doesn’t matter. It works. · GHC home page downloads: o More features but not so stable o Libraries not guaranteed to work o Worth 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.lentczner@gmail.com] Sent: 07 February 2013 17:43 To: Simon Peyton-Jones Cc: andreas.voellmy@gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kostirya@gmail.com; Edsko de Vries; ghc-devs@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

On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier wrote:

Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say "Built on ghc-7.6". By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the "real" GHC version is.

I don't know how closely users look at the "built on" line on the package page. Perhaps they look there, perhaps they don't. Between Bryan and me we build all of our own packages and all HP packages on the latest 3 GHC versions: http://ci.johantibell.com/ https://jenkins.serpentine.com/ That doesn't mean that it would be a bad idea to build all Hackage packages on using more GHC versions, but that won't happen until the Hackage project is unstuck (it has been stuck for years!). -- Johan

johan, how do you and Bryan have those jenkin's nodes setup? (I'm planning to setup something similar for my own use, and seeing how thats setup would be awesome) thanks -Carter On Thu, Feb 7, 2013 at 10:55 PM, Johan Tibell wrote:

On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier wrote:

...

Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say "Built on ghc-7.6". By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the "real" GHC version is.

I don't know how closely users look at the "built on" line on the package page. Perhaps they look there, perhaps they don't.

Between Bryan and me we build all of our own packages and all HP packages on the latest 3 GHC versions:

http://ci.johantibell.com/ https://jenkins.serpentine.com/

That doesn't mean that it would be a bad idea to build all Hackage packages on using more GHC versions, but that won't happen until the Hackage project is unstuck (it has been stuck for years!).

-- Johan

-- You received this message because you are subscribed to the Google Groups "parallel-haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.

On Fri, Feb 8, 2013 at 1:29 AM, Tim Watson wrote:

Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud Haskell and would be very interested in seeing how you've dealt with multiple versions of GHC.

It's easy to parameterize builds in Jenkins based on different values of an environment variable, so Johan and I just have different versions of GHC installed side by side, and then set $GHC_VERSION to "7.6 7.4 7.2 7.0 6.12" (or whatever), put /usr/local/$GHC_VERSION/bin at the front of $PATH, and the right thing happens.

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.lentczner@gmail.com] *Sent:* 07 February 2013 17:43 *To:* Simon Peyton-Jones *Cc:* andreas.voellmy@gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kostirya@gmail.com; Edsko de Vries; ghc-devs@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

On Fri, Feb 08, 2013 at 02:28:20PM +0000, Simon Marlow wrote:

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!

7.2 was billed as a "technology preview" rather than a regular stable release. However, it still required just as much effort as a regular stable release, both for us (we probably spent just as much time trying to make it bug-free, making builds, making docs, etc) and for the community (libraries still needed to adjust dependencies etc). One result of that extra effort was that the 7.4 release got delayed, and the delay was magnified by pushing it over the Christmas period. 7.6 was released roughly according to the regular yearly release plan (although the 7.4 delay made the gap between the two shorter). So in my opinion, 7.2 was a bad idea (but I don't think anyone knew that before we tried it), and I'd agree that we'd be better sticking to not-more-than-yearly major releases. I wouldn't oppose less-than-yearly (e.g. every 18 months) if that makes life easier for distros, library maintainers, the HP, etc. But I wouldn't advocate it either; from GHC's point of view, historically we've always had enough new stuff to justify a new major release after a year. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

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 :

On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow 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

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. Let me suggest once more a possible path, along the lines you suggest · For people who value stability: use the Haskell Platform. Ignore GHC releases. · For people who want as many features as possible: use GHC releases. · For people who want to live on the bleeding edge: build HEAD from source The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed. HP may perfectly sensibly skip an entire release entirely. In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? Simon From: Carter Schonwald [mailto:carter.schonwald@gmail.com] Sent: 09 February 2013 02:45 To: Manuel Chakravarty Cc: GHC Users List; ghc-devs@haskell.org; Andreas Voellmy; Simon Peyton-Jones; Edsko de Vries; Mark Lentczner; Johan Tibell; parallel-haskell Subject: Re: GHC 7.8 release? +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" mailto:chak@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 mailto:johan.tibell@gmail.com>: On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow mailto:marlowsd@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

I agree too - I think it would be great to have non-API-breaking releases with new features. So let's think about how that could work. Some features add APIs, e.g. SIMD adds new primops. So we have to define non-API-breaking as a minor version bump in the PVP sense; that is, you can add to an API but not change it. As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February. Both would be classed as "major", and bump the GHC major version, but the Feb releases would only be allowed to bump minor versions of packages. (except perhaps the version of the GHC package, which is impossible to keep stable if we change the compiler). So how to manage the repos. We could have three branches, but that doesn't seem practical. Probably the best way forward is to develop new features on separate branches and merge them into master at the appropriate time - i.e. API-breaking feature branches could only be merged in after the Feb release. Thoughts? Cheers, Simon On 09/02/13 02:04, Manuel M T Chakravarty 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 mailto:johan.tibell@gmail.com>:

...

On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow mailto:marlowsd@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

We seem to be circling ever closer to consensus here! Yay! I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta: *Haskell Platform* comes out twice a year. It is based on very stable version of GHC, and intention is that people can just assume things on Hackage work with it. These are named for the year and sequence of the release: 2013.2, 2013.2.1, 2013.4,... *Non-API breaking releases* can come out as often as desired. However, the version that is current as of mid-Feb. and mid-Aug. will be the ones considered for HP inclusion. By non-API breaking we mean the whole API surface including all the libraries bundled with GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be explicitly enabled are okay. Additions of new APIs into existing modules are discouraged: Much code often imports base modules wholesale, and name clashes could easily result. These should never bump the major revision number: 7.4.1, 7.4.2... *API breaking releases* happen by being released into a separate channel when ready for library owners to look at them. This channel should probably go through several stages: Ready for core package owners to work with, then HP package owners, then all package owners. I'd imagine this is a several month process. At the end of which, the release can go into the main channel. Such a merge shouldn't happen more than once a year... I think even once every two years is fine (!) To avoid confusion, I'd suggest that while in the separate channel, these release be named with odd number: 7.9, 7.11,..., and when moved to the main channel renamed to even: 7.10, 7.12... This idea of three channels needs to be much more clearly communicated. The warning on the download page is a failure: Googling "ghc" takes you to the home page of GHC which immediately trumpets the "Lastest News" of a release of GHC 7.6.2. Once a user has read that and decided to download, then "STOP!" box is a) going to be skipped as they scan for the download link, and b) if read and followed, causes the "WTF? Why is HP so back rev?" So we need to change the front page so that the three channels are clearly communicated and targeted at the right users. - Mark (BTW: The first few links on the GHC web site are out of date: The second nav link is to a survey that is 7 years old. The License page is 8 years out of date. The FAQ is over a year old.) On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh wrote:

On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:

...

As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February.

That's a non-API release 5 months after the API release.

6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2) 6.12.2 was 4 months after 6.12.1 (.3 was 2 months later) 7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3) 7.2.2 was 3 months after 7.2.1 7.4.2 was 4 months after 7.4.1 7.6.2 was 4.5 months after 7.6.2

so if we do non-API releases, then perhaps it would make sense to stop doing minor releases (unless a release turns out to just be broken).

Thanks Ian

On 10/02/13 15:36, Simon Peyton-Jones wrote:

We seem to be circling ever closer to consensus here! Yay!

Indeed! Good :-)

However, I’m not getting the bit about API changing vs non-API changing.

Firstly I don’t know which APIs are intended. The GHC API is essentially GHC itself, so it changes daily. Maybe you mean the base package? Or what?

I suspect you mean that a “non-API-changing” release absolutely guarantees to compile any package that compiled with the previous version. If so, that is a very strong constraint indeed. We do observe it for patch releases for GHC (e g 7.6.2 should compile anything that 7.6.1 compiles). But I think it would be difficult to guarantee for anything beyond a patch release. Every single commit (and the commit rate is many/day) would have to be evaluated against this criterion. And if it failed the criterion, it would have to go on a API-breaking HEAD. In effect we’d have two HEADs. I can’t see us sustaining this. And I don’t yet really see why it’s necessary. If you don’t want an API-breaking change, stick with the patch releases.

So, we have a channel for non-API-breaking changes already: the patch releases. So that means we already have all three channels!

Mark is asking for major GHC releases every year at the most, preferably less frequently. That means major GHC releases in the sense that we do them now, where libraries change, and a wave of package updates are required to get everything working. Johan, Manuel and Carter are saying that they want releases that add features but don't break code, i.e. a non-API-breaking release, as a way to get the new bits into the hands of the punters sooner. This is something that we don't do right now, and it would entail a change to our workflow and release schedule. It doesn't mean no API changes at all - we would have to allow APIs to be extended, because many feature additions come with new primops, or new supporting code in the ghc-prim or base packages. The package version policy states precisely what it means to extend an API (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most third-party packages will still work so long as we only bump the minor versions of the packages that come with GHC. The GHC package itself would have to be exempt, because it contains every module in GHC, and hence would be impossible to keep stable if we are modifying the compiler to add new features. Of course it's not practical to maintain an extra branch of GHC for non-API-breaking development - two branches is already plenty. So there would need to be an API-freeze for a while between the major release and the non-API-breaking release, during which time people developing API changes would need to work on branches. Is it workable? I'm not sure, but I think it's worth a try. I wouldn't want to see this replace the patchlevel bugfix releases that we already do, and as Ian points out, there isn't a lot of room in the release schedule for more releases, unless we stretch out the timescales, doing major releases less frequently. Cheers, Simon

·Haskell Platform

·Patch-level releases

·New releases

if that’s so, all we need is better signposting. And I’m all for that!

Have I got this right?

Simon

*From:*Mark Lentczner [mailto:mark.lentczner@gmail.com] *Sent:* 09 February 2013 17:48 *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon Peyton-Jones; Mark Lentczner; andreas.voellmy@gmail.com; Carter Schonwald; kostirya@gmail.com; Edsko de Vries; ghc-devs@haskell.org; glasgow-haskell-users *Subject:* Re: GHC 7.8 release?

We seem to be circling ever closer to consensus here! Yay!

I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta:

*Haskell Platform* comes out twice a year. It is based on very stable version of GHC, and intention is that people can just assume things on Hackage work with it. These are named for the year and sequence of the release: 2013.2, 2013.2.1, 2013.4,...

*Non-API breaking releases* can come out as often as desired. However, the version that is current as of mid-Feb. and mid-Aug. will be the ones considered for HP inclusion. By non-API breaking we mean the whole API surface including all the libraries bundled with GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be explicitly enabled are okay. Additions of new APIs into existing modules are discouraged: Much code often imports base modules wholesale, and name clashes could easily result. These should never bump the major revision number: 7.4.1, 7.4.2...

*API breaking releases* happen by being released into a separate channel when ready for library owners to look at them. This channel should probably go through several stages: Ready for core package owners to work with, then HP package owners, then all package owners. I'd imagine this is a several month process. At the end of which, the release can go into the main channel. Such a merge shouldn't happen more than once a year... I think even once every two years is fine (!) To avoid confusion, I'd suggest that while in the separate channel, these release be named with odd number: 7.9, 7.11,..., and when moved to the main channel renamed to even: 7.10, 7.12...

This idea of three channels needs to be much more clearly communicated. The warning on the download page is a failure: Googling "ghc" takes you to the home page of GHC which immediately trumpets the "Lastest News" of a release of GHC 7.6.2. Once a user has read that and decided to download, then "STOP!" box is a) going to be skipped as they scan for the download link, and b) if read and followed, causes the "WTF? Why is HP so back rev?" So we need to change the front page so that the three channels are clearly communicated and targeted at the right users.

- Mark

(BTW: The first few links on the GHC web site are out of date: The second nav link is to a survey that is 7 years old. The License page is 8 years out of date. The FAQ is over a year old.)

On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh mailto:ian@well-typed.com> wrote:

On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:

...

As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February.

That's a non-API release 5 months after the API release.

6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2) 6.12.2 was 4 months after 6.12.1 (.3 was 2 months later) 7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3) 7.2.2 was 3 months after 7.2.1 7.4.2 was 4 months after 7.4.1 7.6.2 was 4.5 months after 7.6.2

so if we do non-API releases, then perhaps it would make sense to stop doing minor releases (unless a release turns out to just be broken).

Thanks Ian

On Sun, Feb 10, 2013 at 09:02:18PM +0000, Simon Peyton-Jones wrote:

You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested.

But the way you test new features is to write programs that use them, and programs depend on libraries. Thanks Ian

On Sun, Feb 10, 2013 at 09:30:23PM +0000, Simon Peyton-Jones wrote:

| > You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries.

That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy.

But that's not what happens. GHC 7.8 is released. Someone installs it in order to try to use TypeHoles when developing their program. But their program depends on text, so they send Bryan a mail saying that text doesn't build with 7.8. And so the wave of updates begins. Thanks Ian

On Sun, Feb 10, 2013 at 3:30 PM, Simon Peyton-Jones wrote:

| > You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries.

That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than "compile HEAD" gives us.

Simon

Fitting: http://xkcd.com/1172/ (sorry, I couldn't resist) -- Gaby

On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh wrote:

On Sun, Feb 10, 2013 at 09:02:18PM +0000, Simon Peyton-Jones wrote:

...

You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested.

But the way you test new features is to write programs that use them, and programs depend on libraries.

Thanks Ian

Releasing GHC early and often (possibly with API breakage) isn't really the problem. The real problem is how to coordinate with library authors (e.g. Haskell Platform), etc. I suspect GHC should continue to offer a platform for research and experiments. That is much harder if you curtail the ability to release GHC early and often. -- Gaby

While I'm notionally in favor of decoupling API-breaking changes from non-API breaking changes, there are two major difficulties: GHC.Prim and Template Haskell. Should a non-API-breaking change mean that GHC.Prim is immutable? If so, this greatly restricts GHC's development. If not, it means that a large chunk of hackage will become unbuildable due to deps on vector and primitive. With Template Haskell the situation is largely similar, although the deps are different. What I would like to see are more patch-level bugfix releases. I suspect the reason we don't have more is that making a release is a lot of work. So, Ian, what needs to happen to make more frequent patch releases feasible? On Mon, Feb 11, 2013 at 7:42 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

Well said. Having a more aggressive release cycle is another interesting perspective. On Feb 10, 2013 6:21 PM, "Gabriel Dos Reis" wrote:

...

On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh wrote:

...

On Sun, Feb 10, 2013 at 09:02:18PM +0000, Simon Peyton-Jones wrote:

...

You may ask what use is a GHC release that doesn't cause a wave of

updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested.

But the way you test new features is to write programs that use them, and programs depend on libraries.

Thanks Ian

Releasing GHC early and often (possibly with API breakage) isn't really the problem. The real problem is how to coordinate with library authors (e.g. Haskell Platform), etc.

I suspect GHC should continue to offer a platform for research and experiments. That is much harder if you curtail the ability to release GHC early and often.

-- Gaby

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On 10 February 2013 13:02, Simon Peyton-Jones wrote:

What I am still missing is this:

| Mark is asking for major GHC releases every year at the most, preferably | less frequently. That means major GHC releases in the sense that we do | them now, where libraries change, and a wave of package updates are | required to get everything working.

What causes the "wave of package updates"? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP.

But there is no reason why package authors should respond to GHC releases, provided we signpost it accurately.

You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. Of course we could just not do that, and say "build from source", but a release brings a welcome discipline. But under this story, release or not-release would be a Little Deal, not a Big Deal. The benefits are modest; the costs are modest.

In short, I'm continuing to propose that we stick to the current story, but signpost it better. If it ain't broke, don't fix it --- or at least fix only the bits that are broken, which is the signposting.

My understanding of the proposed changes (which I'm also supportive of) is to separate GHC improvements that break existing libraries (or perhaps even simply add language level features), and those that are improvements under-the-hood (e.g., bug fixes, performance improvements). So rather than 7.8 be a huge single release containing new type level features, SIMD, the new code-generator. There would be two releases, one containing just say the new-code-generator, improvements to the IO manager, potentially also DPH... another release would containing new language level improvements. So then HP can benefit from improvements to the existing language and API without having to also pull in breaking (or just extending) changes... It's the issue of a research compiler Vs. and industrial compiler and managing that more explicitly in the release model. Cheers, David

Simon

| | Johan, Manuel and Carter are saying that they want releases that add | features but don't break code, i.e. a non-API-breaking release, as a way | to get the new bits into the hands of the punters sooner. This is | something that we don't do right now, and it would entail a change to | our workflow and release schedule. | | It doesn't mean no API changes at all - we would have to allow APIs to | be extended, because many feature additions come with new primops, or | new supporting code in the ghc-prim or base packages. The package | version policy states precisely what it means to extend an API | (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most | third-party packages will still work so long as we only bump the minor | versions of the packages that come with GHC. | | The GHC package itself would have to be exempt, because it contains | every module in GHC, and hence would be impossible to keep stable if we | are modifying the compiler to add new features. | | Of course it's not practical to maintain an extra branch of GHC for | non-API-breaking development - two branches is already plenty. So there | would need to be an API-freeze for a while between the major release and | the non-API-breaking release, during which time people developing API | changes would need to work on branches. | | Is it workable? I'm not sure, but I think it's worth a try. I wouldn't | want to see this replace the patchlevel bugfix releases that we already | do, and as Ian points out, there isn't a lot of room in the release | schedule for more releases, unless we stretch out the timescales, doing | major releases less frequently. | | Cheers, | Simon | | | > ·Haskell Platform | > | > ·Patch-level releases | > | > ·New releases | > | > | > if that’s so, all we need is better signposting. And I’m all for that! | > | > Have I got this right? | > | > | > Simon | > | > *From:*Mark Lentczner [mailto:mark.lentczner@gmail.com] | > *Sent:* 09 February 2013 17:48 | > *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon | > Peyton-Jones; Mark Lentczner; andreas.voellmy@gmail.com; Carter | > Schonwald; kostirya@gmail.com; Edsko de Vries; ghc-devs@haskell.org; | > glasgow-haskell-users | > *Subject:* Re: GHC 7.8 release? | > | > We seem to be circling ever closer to consensus here! Yay! | > | > I think the distinction of non-API breaking and API breaking release is | > very important. Refining SPJ's trifecta: | > | > *Haskell Platform* comes out twice a year. It is based on very | > stable version of GHC, and intention is that people can just assume | > things on Hackage work with it. These are named for the year and | > sequence of the release: 2013.2, 2013.2.1, 2013.4,... | > | > *Non-API breaking releases* can come out as often as desired. | > However, the version that is current as of mid-Feb. and mid-Aug. | > will be the ones considered for HP inclusion. By non-API breaking we | > mean the whole API surface including all the libraries bundled with | > GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions | > of features that must be explicitly enabled are okay. Additions of | > new APIs into existing modules are discouraged: Much code often | > imports base modules wholesale, and name clashes could easily | > result. These should never bump the major revision number: 7.4.1, | > 7.4.2... | > | > *API breaking releases* happen by being released into a separate | > channel when ready for library owners to look at them. This channel | > should probably go through several stages: Ready for core package | > owners to work with, then HP package owners, then all package | > owners. I'd imagine this is a several month process. At the end of | > which, the release can go into the main channel. Such a merge | > shouldn't happen more than once a year... I think even once every | > two years is fine (!) To avoid confusion, I'd suggest that while in | > the separate channel, these release be named with odd number: 7.9, | > 7.11,..., and when moved to the main channel renamed to even: 7.10, | > 7.12... | > | > This idea of three channels needs to be much more clearly communicated. | > The warning on the download page is a failure: Googling "ghc" takes you | > to the home page of GHC which immediately trumpets the "Lastest News" of | > a release of GHC 7.6.2. Once a user has read that and decided to | > download, then "STOP!" box is a) going to be skipped as they scan for | > the download link, and b) if read and followed, causes the "WTF? Why is | > HP so back rev?" So we need to change the front page so that the three | > channels are clearly communicated and targeted at the right users. | > | > - Mark | > | > (BTW: The first few links on the GHC web site are out of date: The | > second nav link is to a survey that is 7 years old. The License page is | > 8 years out of date. The FAQ is over a year old.) | > | > On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh mailto:ian@well-typed.com> wrote: | > | > On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote: | > > | > > As a straw man, let's suppose we want to do annual API releases in | > > September, with intermediate non-API releases in February. | > | > That's a non-API release 5 months after the API release. | > | > 6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2) | > 6.12.2 was 4 months after 6.12.1 (.3 was 2 months later) | > 7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3) | > 7.2.2 was 3 months after 7.2.1 | > 7.4.2 was 4 months after 7.4.1 | > 7.6.2 was 4.5 months after 7.6.2 | > | > so if we do non-API releases, then perhaps it would make sense to stop | > doing minor releases (unless a release turns out to just be broken). | > | > | > Thanks | > Ian | >

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

* Manuel M T Chakravarty [2013-02-10 21:17:07+1100]

Re (2): we should encourage contributors to fork the GHC repos on GitHub and work in those. That makes it easy for everybody to build forks (which will be longer-lived under the above policy) and creating a fork doesn't require any special privileges in GHC repos. Finally, we can use GitHub pull requests to track contributions that are pending integration. This is IMHO also much nicer than attaching patches at Trac tickets.

FYI, it is also possible to create pull requests from one branch to another. So, for people who already have push-access to the main repo it is not strictly necessary to fork in order to submit a pull request. Roman