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
