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

[Andrew Lelechenko]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-releases/attachments/20240122/63d0cc6c/attachment-0001.html>