The GHC developers are very pleased to announce the release of GHC 9.12.4.
Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.
GHC 9.12.4 is a bug-fix release fixing many issues of a variety of
severities and scopes, including:
Fixed a critical code generation regression where sub-word division produced
incorrect results (#26711, #26668), similar to the bug fixed in 9.12.2
Numerous fixes for register allocation bugs, preventing data corruption
when spilling and reloading registers
(#26411, #26526, #26537, #26542, #26550)
Fixes for several compiler crashes, including issues with CSE (#25468),
and the simplifier(#26681), implicit parameters (#26451), and the type-class
specialiser (#26682)
Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903)
Fixed LLVM backend miscompilation of bit manipulation operations
(#20645, #26065, #26109)
Fixed associated type family and data family instance changes not triggering
recompilation (#26183, #26705)
Fixed negative type literals causing the compiler to hang (#26861)
Improvements to determinism of compiler output (#26846, #26858)
Fixes for eventlog shutdown deadlocks (#26573)
and lost wakeups in the RTS (#26324)
Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770)
Fixes for the bytecode compiler, PPC native code generator, and Wasm backend
The runtime linker now supports COMMON symbols (#6107)
Improved backtrace support: backtraces for error exceptions are now
evaluated at throw time
NamedDefaults now correctly requires the class to be standard or have an
in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882)
… and many more
A full accounting of these fixes can be found in the release notes. As
always, GHC’s release status, including planned future releases, can be found on
the GHC Wiki status.
We would like to thank these sponsors 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.
Would it make sense to delay the announcements of new GHC versions here until they become available with ghcup, at least in the vanilla branch? After all, ghcup is the most popular installation method, if we assign relevance to the survey State of Haskell 2025 results .
Based on recent experience, it seems that it takes in average a week for the new version to get available with ghcup. It would be nice that when I read the announcement, I can directly crank up ghcup to deliver the new version to me.
Interestingly, I was not aware that 9.12.4 will be released this Friday.
I’ve spent months trying to be more in the loop. We created a giant policy document, created a matrix channel for release communication, I’ve had calls over calls on this topic… but it seems in the end, it still doesn’t quite work. I get no heads up.
So then I was in the mountains without access to a laptop the entire weekend. I’ll get to it when I have the time. If you don’t coordinate with me, there will be delays.
While it seemed we’re in soft agreement that no other RC should be done, it wasn’t entirely obvious to me how the release is going to proceed.
And even in the absence of such unclarities, explicit communication is better than assuming everyone marks the exact date in their calendar and assumes GHC releases are always on point (which they are not).
That is fair. It was not helped that I had some things to sort out in my personal live last week which is why I hadn’t yet responded further on that ticket either last week.
Beyond that not sure how to improve on this. Release candidates are of course always intended to be final, but often issues are found which restart the clock. Which means there is a non-trivial risk any promised release date might not hold unless we move away from giving X period of time for every RC completely.
To be clear… it’s fine with me if there’s a delay between release and ghcup availability.
It’s just that end users are constantly asking that question: when does it appear in ghcup. The only way to improve that is to ping me directly, ask whether I have time on the day of the release (or close before) and then coordinate.
These days I’m less available on weekends, so if you drop anything on Friday without notice, it won’t be there until ~mid of next week.
When users ask when a new version of ghc will be available in ghcup, are they implying it’s not showing up fast enough? I too usually wonder when a new version is available, so I would be one to ask that, but I personally think that a one week delay is fine, and many others might agree.
GHCup is a distribution channel. As such there may be a lag of 1-2 weeks after a release of e.g. GHC has concluded. This involves manual QA, review of the metadata, creation of unofficial bindists, etc.
GHCup is not involved in upstream’s CI infrastructure or release process. It’s a separate project.
Please do not ask when the new version of tool XY will be available.
And following @hasufell’s work in making it available on GHCup, 9.12.4 is now also available on the playground.
In contrast to hasufell, I have made zero attempts to get involved in / be informed about the GHC release process. New GHC releases become available on the playground by me monitoring the GHCup yaml metadata file for changes and then (partially manually) adding it to the playground server.
So far I have always been available soon enough after the release comes on GHCup that delays have been relatively short (less than 2 days generally, I think). I don’t see any reason to change the status quo, though it is possible that awkward timing could lengthen this delay sometimes. If people are unhappy with the current situation for the playground, I’m happy to discuss (though probably better in a separate thread).
My request was to the GHC team to wait with the big announcement until GHCup ships it (in prereleases or vanilla, not necessarily the default channel).
Basically, in the release procedure, there would be something like:
n. Publish artifacts at downloads.haskell.org etc.
n+1. Open a PR against ghcup-metadata
n+2. When the PR has been merged, announce the release.
Additionally, it might make sense to announce the release to more specialist mailing lists (like ghc developers) for the audience that need to learn about the release immediately.
The fact that contributing is hard has many reasons and yes, you could say it’s partly my fault too.
Sure, I can invest more time into creating a yaml spec, versioning it, documenting the differences, ensuring I never break format backwards compatibility (which is the case), maybe add support for the more expressive Dhall config language, implement revisions, etc.
But in the end you also have to understand what you’re doing. Distribution and packaging is boring work, where small mistakes can be unrecoverable to the point that you have to reinstall the whole shebang. You can’t always treat it as “fix as you go” as I’ve read on multiple occasions now. It requires a careful attitude.
Given that I’m currently rewriting large parts of GHCup to be able to ship arbitrary bindists/binaries, I’ll have to invest more time into making the format more robust anyway, add bubblewrap support for untrusted Makefiles and document how to maintain a channel properly.
So maybe this is the way to go. Users who can’t wait a single day will have to use upstream metadata.
@hasufell Thanks for your explanation, but I do not understand why you phrase your explanation as reply to my question. You were not even the target of my request, but "The GHC team”.
Please be aware that these are unofficial and untested binary distributions of GHC on Alpine Linux.