[GHC DevOps Group] New release process

[Michael Snoyman]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171023/4ac5ffea/attachment.html>