[GHC DevOps Group] New release process

[Manuel M T Chakravarty]

> Simon Peyton Jones <simonpj at microsoft.com>:
> 
> | * 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.
> 
> 10 months is long.  I thought we were aiming for 6 months max, so as to reduce pressure to ”just get this in"?

I think, the plan was to branch 3 months before the release, so 9 months. This is significantly better than the current situation if you include the current release delays.

> If we fork 4 months before release, does that mean that nothing makes it into the release branch except bug fixes?  If we have better CI do we really need 4 months to stablise?

This is something we need to discuss and fix. There are various options. A common one is to have beta releases for a while before the first RC. Different projects have different policies, but during beta releases new features are often still allowed in if they don’t destabilise too much. (Usually these are only features that were previously already planned for that release, but didn’t quite make it in time for the branching.) However, under no circumstances will a release be delayed only to wait for a new feature.

Then, during RCs, it is strictly only bug fixing.

In other words, a rewritten type checker really ought to be in *before* the release branch is cut. However, a new language extension that has no impact when it is not enabled, could well land during beta. We need to determine the exact rules. 

As Mathieu suggested, I will start a Wiki page, where we refine this until we are all happy.

Manuel

> S
> 
> | -----Original Message-----
> | From: Ghc-devops-group [mailto:ghc-devops-group-bounces at haskell.org] On
> | Behalf Of Boespflug, Mathieu
> | Sent: 23 October 2017 23:12
> | To: Manuel M T Chakravarty <manuel.chakravarty at tweag.io>
> | Cc: ghc-devops-group at haskell.org
> | Subject: Re: [GHC DevOps Group] New release process
> | 
> | 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> | > b.com%2Fsnowleopard%2Fhadrian%2Fissues%2F440&data=02%7C01%7Csimonpj%40
> | > microsoft.com%7C29cefad3d8874c85cfcf08d51a632d28%7C72f988bf86f141af91a
> | > b2d7cd011db47%7C1%7C0%7C636443935617660899&sdata=VtDfZIKncpArPK0etDYFM
> | > YCHiqM9LbwAnnco0TuCV7o%3D&reserved=0
> | >
> | > 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