[GHC-Releases] GHC 9.10 release schedule and core library status

[Mikolaj Konarski]

> * Mikolaj, are we looking for Cabal 3.12 or carrying on with 3.10.3+? There are at least two important features missing from Cabal 3.10: semaphores and multiple home units.

We plan to have Cabal 3.12 in time.

On Tue, Jan 23, 2024 at 12:59 AM Andrew Lelechenko
<andrew.lelechenko at gmail.com> wrote:
>
> Thanks, Ben. (I’m not subscribed to mail lists CC’d, so I expect this reply to be missing from them)
>
> CC’ng Matthew Craven on behalf of bytestring, Xia Li-yao on behalf of text, Lei Zhu, Carsten König and Miao ZhiCheng on behalf of array (it’s not orphaned).
>
> Several blockers from the top of my head:
>
> * Bump containers submodule to 0.7, long overdue. AFAIR blocked on https://github.com/judah/haskeline/pull/186 - Ben, are you able to merge it?
>
> * Bump filepath submodule to 1.5 and add os-string to boot libraries. Julian might remember better, but AFAIR there are no blockers, just someone has to upgrade several submodules at once.
>
> * GHCJS progress depends on merging outstanding PRs for bytestring and text to provide pure Haskell implementations, and I imagine Sylvain (CC’d) would wish them to be merged and released before GHC 9.10 is forked.
>
> * Mikolaj, are we looking for Cabal 3.12 or carrying on with 3.10.3+? There are at least two important features missing from Cabal 3.10: semaphores and multiple home units.
>
> Best regards,
> Andrew
>
> On 22 Jan 2024, at 16:00, Ben Gamari <ben at well-typed.com> wrote:
>
> Hi all,
>
> First, apologies for the silence regarding the 9.10 fork; I was hoping
> to improve our communications with boot library authors in the run-up to
> GHC 9.10 but illness unfortunately took me largely out of commission for
> a first few weeks of the year. Happily, things are looking rosier now.
>
> Having had a chance to look at the 9.10 branch and the release goals, I
> am planning to cut the fork for GHC 9.10 around a month from today, on
> 23 Februrary 2024. This leaves around a month of time to merge the
> `ghc-internals` split and a few of the other bits of work that remain
> outstanding. We anticipate the first alpha release will come a week
> after the fork (see the Milestone [1] for further details).
>
> How does this sound to you?
>
> For organizational purposes, it would be helpful if we designated a
> coordinating maintainer for each of our boot packagers for the 9.10 release.
> My understanding is that our boot libraries have the following primary
> maintainers but don't hesitate to let me know if you believe this to be
> incorrect:
>
> | Package         | Maintainer                 |
> | --------------- | -------------------------- |
> | Cabal           | Mikolaj Konarski           |
> | Win32           | Tamar Christina            |
> | array           | (orphaned)                 |
> | binary          | Lennart Kolmodin?          |
> | bytestring      | Andrew Lelechanko          |
> | containers      | David Feuer                |
> | deepseq         | Melanie Phoenix            |
> | directory       | Phil Rufflewind            |
> | exceptions      | Ryan Scott                 |
> | filepath        | Julian Ospald              |
> | haddock         | Hecate                     |
> | haskeline       | Judah Jacobson             |
> | hpc             | David Binder               |
> | mtl             | Emily Pillmore             |
> | parsec          | Oleg Grenrus               |
> | process         | Michael Snoyman            |
> | stm             | Simon Marlow               |
> | terminfo        | Judah Jacobson             |
> | text            | Andrew Lelechanko          |
> | time            | Ashley Yakeley             |
> | transformers    | Ross Paterson              |
> | unix            | Julian Ospald              |
>
> It would be great if each maintainer could let me know what they would
> like to do for the 9.10 release. In general we would love to have the
> set of boot libraries pinned down at least in version by the second
> alpha, which we are planning for the second week of March 2024. Does
> this sound reasonable?
>
> As always, I would encourage core library maintainers to be conservative
> in their plans for a GHC release and avoid introducing major features or
> refactorings in their release. Such changes both add risk to the release
> schedule and complicate the users' migration paths; consequently, they
> are ideally best held for releases asynchronous to the GHC release
> process.
>
> Thanks again for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380#tab-issues
>
>