Release 3.4 planning

[phadej]

The GHC 8.12 plans have been announced https://mail.haskell.org/pipermail/ghc-devs/2020-May/018851.html

• Mid-June 2020: Aim to have all major features in the tree
• Late-June 2020: Cut the ghc-8.12 branch
• June - August 2020: 3 alpha releases
• 1 September 2020: beta release
• 25 September 2020: Final 8.12.1 release

I suggest that we cut the 3.4 branch at the end of June, i.e. after first GHC alpha release. So we can fix the most obvious stuff in master. (Backporting is costly). This also means that all features should be in by that date. (again backporting is costly).

Perfectly after the branch is cut, we will need to backport only bugfixes. To make that easy, let us merge all code-shuffling PRs (#6747 , #6729, #6746 and specifically its possible followups) during this month (2020-05).

Note, we are locked into GHCs "6"-month release cycle for good and bad. In other words, there is no pressure to get stuff into 3.4 specifically.

There are around 60 issues in https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.4. That list is probably both too large (contains stuff which won't make it, and hardly is "must"), and doesn't contain all stuff we can would like to be included. I'll go through issues soon:

• pinging the assignees whether they will have time to complete them by mid-June
• otherwise I'll demilestone them

To specifically mention, I don't consider #6719/#6700 and #6616 must features. Specifically, I'd rather look closely on #6616 (GHC CI infrastructure for releases) only after 3.4 branch is cut.

[m-renaud]

Do we want to try and have a barebones (aka. still experimental) cabal env as part of the 3.4 release for folks to try out and to get feedback on? There are several open issues around the existing cabal install --lib, so if we don't go all the way with cabal env we should probably have some fix (even if temporary) for their use cases (I have the tidal one in mind in particular). wdyt?

[phadej]

We have burned too much about adding "experimental" features (c.f. public multilibs, usable but not production ready). So rather not. Also #6481 doesn't really have enough support comments for me being comfortable going forward. Maybe we should ask larger community what to do first, even I personally do like cabal env idea.

[m-renaud]

Fair enough, in which case I feel like we should provide some resolution to the tidal issue, or is the resolution: "Manually remove the environment before re-installing"?

[samuela]

#6616 should be more or less ready as soon as we get Windows support.

[phadej]

@bgamari, when we can expect the first GHC-8.12 alpha?

[phadej]

My plan is to cut 3.4 branch tomorrow (Thu 2020-07-09).

[blackgnezdo]

Is there sufficient clarity about the timeline for this release or is it determined by GHC 9.0? Any blockers on cabal side? @bgamari do you have any gossip to share?

[phadej]

It is determined by GHC-9.0

[blackgnezdo]

Are there notable risks to pushing cabal 3.4 to hackage ahead of the formal ghc 9.0 now that 9.0.1 is tagged in the repository?

[Bodigrim]

@blackgnezdo what is missing on Hackage?
http://hackage.haskell.org/package/Cabal-3.4.0.0
http://hackage.haskell.org/package/cabal-install-3.4.0.0

[blackgnezdo]

Oops, I lost the race. I checked yesterday and it appeared overnight. Thanks!

[emilypi]

Cabal-3.4.0.0 and cabal-install-3.4.0.0 are fully released as of last weekend 🎉