[GHC DevOps Group] New release process

[Manuel M T Chakravarty]

Yes, I will start a wiki page on that.

Manuel

> Boespflug, Mathieu <m at tweag.io>:
> 
> 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
>> 
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group