The GHC developers are happy to announce the availability of GHC 9.4.8. Binary
distributions, source distributions, and documentation are available on the
[release page](/download_ghc_9_4_8.html).
This release is primarily a bugfix release addressing a few issues
found in the 9.4 series. These include:
* A fix for a recompilation checking bug where GHC may miss changes in
transitive dependencies when deciding to relink a program (#23724).
* A fix for a code generator bug on AArch64 platforms resulting in invalid
conditional jumps (#23746).
* Support for `-split-sections` on Windows.
* Enabling `-split-sections` for various Linux and Windows binary distributions,
enabling GHC to produce smaller binaries on these platforms.
* And a few other fixes
A full accounting of changes can be found in the [release notes]. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and
other anonymous contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years. Finally,
this release would not have been possible without the hundreds of open-source
contributors whose work comprise this release.
As always, do give this release a try and open a [ticket][] if you see
anything amiss.
Happy compiling!
-Zubin
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
[release notes]: https://downloads.haskell.org/~ghc/9.4.8/docs/users_guide/9.4.8-notes.html
Hello,
Over the past few months, I have looked at tickets labeled "Priority:
highest" to get a feel for things. I looked at the three stalest once a
fortnight using this link.
https://gitlab.haskell.org/ghc/ghc/-/issues/?sort=updated_asc&state=opened&…
I managed to find some that could be closed, some that could be
deprioritized, and some that had fallen through the cracks. Overall it felt
really nice.
Now I've started seeing the same issues, meaning I've worked my way through
the entire list. So I think all of the remainders are current and valid.
Having done that, I decided I'd try looking at "Priority: high" tickets.
Unfortunately the same triage strategy won't work. While "highest" says to
me, "Hey, we need to fix this!", it's not clear what "high" means. I think
a mature project like GHC may very well have many tickets that are
important, but not important enough to halt other work. That means these
tickets may just be stale and that's that. But then how might I review
them? My strategy of simply looking at the 3 stalest once a fortnight won't
work anymore, because it'll just be the same three each time. :)
At least with "Priority: Highest" tickets, I felt justified commenting,
"Hi, is this still valid?" if I had nothing else meaningful to add. That
would push the ticket to the bottom of the queue.
Would people mind if I do the same thing with "Priority: High" tickets? I
do worry it might cause useless churn. Nonetheless, I think a slow review
like this is valuable, since undoubtedly there are tickets that can be
closed or reprioritized.
I could also do something dull like toggle some metadata, e.g. assign and
then unassign myself, which would also "refresh" the ticket and push it to
the bottom of the list.
Does anybody have any better ideas?
