Re: GHC 7.8 release?

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