[GHC DevOps Group] New release process

[Boespflug, Mathieu]

> It would be nice to have a fleshed out branching model on a wiki page.

And I forgot to mention... one that explains what the branching model
and schedule mean for backwards compatibility.
--
Mathieu Boespflug
Founder at http://tweag.io.


On 24 October 2017 at 00:12, Boespflug, Mathieu <m at tweag.io> wrote:
> Hi Manuel,
>
> whoa 6.4... throwback from the past! ;)
>
> The main point of more frequent releases is to get new features in the
> hand of users faster. This in turn leads to a more reliable process,
> because there is less pressure to integrate features late in the
> release cycle.
>
> If I understand the proposed release calendar, the lifecycle of a new
> feature is:
>
> * Get a Diff reviewed and merged into master.
> * Merge needs to happen 3-4 months (according to the dates you
> mention) before the next release.
> * If the merge happens immediately after the release branch is cut,
> then the feature technically has to wait out up to 10 months (if on a
> 6 month release cycle) before making it into a release.
>
> Am I understanding this right?
>
> It would be nice to have a fleshed out branching model on a wiki page.
>
>
> On 23 October 2017 at 07:49, 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
>>