[GHC DevOps Group] New release process

[Boespflug, Mathieu]

Hi Michael,

we frequently have to resort to awkwardly pinning builds to custom
versions of GHC because the latest major release broke things but at
the same time contain essential new functionality. So I agree that
more frequent point releases would be desirable.

A compounding factor is that many bugs that could have been caught
before a release are not. Presumably like you, the last few major
releases have all broken at least one of our packages (even the
Stackage ones). That is why like you, we fear GHC major releases.

At the same time, the current release model is that no new
functionality makes into point releases. That makes sense: many new
features make pervasive changes to the compiler that interact with
others in non-trivial ways, so releasing them in batch at known
intervals saves time. It's also easier for downstream packages to
track which compiler versions they're compatible with.

That is why Manuel presented a PoC at HIW this year for adding an
extra channel in Stackage that tracks GHC HEAD, to detect breakage in
the ecosystem early before the release. Releasing more frequently
means changes between major versions are more incremental, easier to
adapt to, and amount to  "some plans allowing for introducing new
functionality [earlier] without breaking backwards compatibility",
*depending on how we amend the BC policy*. Leveraging Stackage means
BC issues can be caught very early in a change's lifecycle - long
before a new release is even cut.

Best,
--
Mathieu Boespflug
Founder at http://tweag.io.


On 23 October 2017 at 10:55, Michael Snoyman <michael at snoyman.com> wrote:
> I'm likely going to be a contrary opinion here: I'd prefer _less_ frequent
> GHC releases, not more frequent. Or at the very least: if we're talking
> about major releases with intentional breakage, I see multiple problems:
>
> * Many libraries are subscribing to a "3 versions" support policy. Having a
> breaking release every 6 months means that libraries will be phasing out
> support for a GHC release after only 1.5 years.
> * From a Stackage perspective, I see how long it takes for the ecosystem to
> catch up to a new GHC release. Depending on what it means for the ecosystem
> to have caught up, I'd put that number anywhere from 2-4 months.
>
> Personally, I'd be much more interested in seeing:
>
> * More frequent point releases, with more guarantees of backwards
> compatibility between releases. We've had situations in the past where point
> releases have broken a significant number of packages, and it would be great
> if we could work towards avoiding that with automated testing.
> * Perhaps some plans allowing for introducing new functionality in point
> releases without breaking backwards compatibility.
>
> From the standpoints of a package author, a tooling maintainer, and someone
> helping companies with commercial rollouts of Haskell code, I've grown to
> fear GHC releases. I'd rather we fix those problems before increasing
> frequency.
>
> On Mon, Oct 23, 2017 at 8:49 AM, Manuel M T Chakravarty
> <manuel.chakravarty at tweag.io> wrote:
>>
>> One of the stated goals of our effort is to move to calendar-based
>> 6-monthly releases of GHC. To this end, I had a conversation with Ben a
>> while ago, where discussed the following schedule for v6.4 & v6.6:
>>
>>   6.4 release planned for Feb
>>   - Branch in Nov
>>
>>   6.6 release ought to then be in Aug
>>   - Branch in May
>>
>>   Pre-release schedule
>>   - On cutting the branch, alpha release
>>   - Then, a beta every two weeks until 4 weeks before the targeted release
>> date
>>   - RC1 four weeks before the targeted release date
>>   - RC2 two weeks before the targeted release date
>>
>> For this to be realistic, we do need to have the automatic release
>> artefact building in place by the time of cutting the v6.4 branch. This
>> doesn’t leave us much time to get this up and running.
>>
>> Ben, this also requires us to settle
>>
>>   https://github.com/snowleopard/hadrian/issues/440
>>
>> soon.
>>
>> We need to discuss a policy of what can go into the release branch after
>> it has been cut. IMHO, it cannot be major features, but only small changes
>> and fixes until RC1. Then, only fixes.
>>
>> What do you all think?
>>
>> Cheers,
>> Manuel
>>
>>
>> _______________________________________________
>> Ghc-devops-group mailing list
>> Ghc-devops-group at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>>
>
>
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>