The GHC developers are happy to announce the availability of GHC 9.8.3. Binary
distributions, source distributions, and documentation are available on the release page.
This release is primarily a bugfix release the 9.8 series. These
include:
Significantly improve performance of code loading via dynamic linking (#23415)
Fix a variety of miscompilations involving sub-word-size FFI arguments
(#25018, #24314)
Fix a rare miscompilation by the x86 native code generator (#24507)
Improve runtime performance of some applications of runRW# (#25055)
Reduce fragmentation when using the non-moving garbage collector (#23340)
Fix source links in Haddock’s hyperlinked sources output (#24086)
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.
It has been that way for a while that some groups have to watch GHC development and releases (including CLC… figuring out if base MRs were merged/released/mis-implemented or API got accidentally broken, etc.).
A proper release process would contact the involved parties, have a clear process and publicly visible documentation of what is going to happen and when.
Right now I either have to be actively involved in release matters or watch mailing lists, issues trackers and have weekly calls with GHC devs. Again: that is not a sustainable strategy to deal with volunteers time.
It sounds like the problem isn’t that mailing lists (or its successor, Discourse) are used. The problem is they are not used.
I suppose there’s information you would like to get that you aren’t getting. What information is that, exactly? Is it the version number of libraries that will be included in a release?
A minor 9.6 and 9.8 release were cut using some filepath version (1.4.200 I believe)
GHC’s master branch was updated to higher major version 1.5.0.0
Date: Tue Jan 23 12:44:38 2024 -0500
Bump filepath to 1.5.0.0
In preparation for the 9.6 release the filepath version on the 9.6 branch was updated to 1.4.300.1
Date: Fri Mar 22 14:11:31 2024 +0530
Bump filepath submodule to 1.4.300.1
Usually backports are done by ensuring changes are on master first and then backporting them. Here that would have meant doing a breaking change for a boot library in a minor ghc version. Which we like to avoid. So instead the version of file path was only updated on the ghc-9.6 branch.
This meant there wasn’t a natural MR to backport for the 9.8.3 release and we failed to bump the filepath version.
To prevent this in the future we will add a check to the release checklist that ensures that for any release ghc-A.B.C boot library versions should not be older than for the latest ghc-A.B-1 release at the time of release.
E.g. for release 9.8.3 we would have check that library versions are equal or higher than what is in the latest 9.6 release and this would have prevented this bug.
It’s quite unfortunate that this has happened, but given that it’s a minor version difference I hope it will not cause too much breakage.
Note that such a check still can’t guarantee that moving to a higher major ghc version will never result in an older boot library.
For example should we release ghc-9.6.7 in a few months we might reasonably upgrade a boot library to a versions newer than the ones 9.8.3 shipped with.
This is just a manifestation of a broader issue and adding more tests will not fix it.
I don’t have the impression that the release process is user or stakeholder focussed. It’s developer focussed.
Sure, you can just see yourself as an independent distributor of some core libraries and don’t really have to talk or coordinate with anyone.
The same goes for the consumers of your bindists.
But I’m not sure that’s a good strategy.
Ben did start a document some time ago afair, outlining the specific versions of all core libraries that will be included. I don’t remember anymore where, because it was on a mailing list I wasn’t subscribed to and I couldn’t reply.
I don’t know what happened to it and this is just one of the things I would expect from a user/stakeholder centric release process.
(For example it caused stack to be dropped from current Stackage Nightly and likely Stackage LTS 23. On the plus side we now have cabal-install again…)
Would it be possible to update the version-history document with the versions for 9.8.3? I consult this page for almost every upgrade to see what has changed. Of course, it is possible to get to this information, but I thought it would be nice to either update that page, or maybe deprecate it entirely if I am the only one using it.
Updating that page is on the release checklist, but like any manual process it is prone to human error. I think Ben took a break after the release was finished (understandable, it’s a lot of frustrating work), and I imagine it’ll get fixed up when he returns.
Can you clarify if this was a bounds issue or is stack simply not buildable or otherwise broken with this version of filepath? Either is regrettable but the later would still be worse. I briefly checked the stack issue tracker but couldn’t find a ticket that seemed relevant.
