[GHC DevOps Group] New release process

[Simon Peyton Jones]

| * 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"?

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?

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