GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Marlow <marlowsd at gmail.com>:
> 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?

That sounds sensible to me. 

Related to this, then, is the management of branches, which, I think, we can improve in two ways:

(1) Make all library packages into submodules.
(2) Fork-instead-of-branch and use GitHub pull requests.

Re (1): submodules make tracking of synchronised branches across multiple repos simpler. Yes, they also have their pitfalls, but given that we are already using submodules extensively, we need to deal with those pitfalls anyway. So, why not reap the benefits, too?

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.

Manuel

> 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 <johan.tibell at gmail.com <mailto:johan.tibell at gmail.com>>:
>>> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at gmail.com
>>> <mailto: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
>> 
> 
> -- 
> 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 at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
>