GHC 7.8 release?
jwlato at gmail.com
Mon Feb 11 03:09:56 CET 2013
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
On Mon, Feb 11, 2013 at 7:42 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:
> Well said. Having a more aggressive release cycle is another interesting
> On Feb 10, 2013 6:21 PM, "Gabriel Dos Reis" <gdr at integrable-solutions.net>
>> On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh <ian at well-typed.com> 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
>> > 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 at haskell.org
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users