The Haskell Programming Language's blog @blog.haskell.org.web.brid.gy

GHC 9.14.1-alpha1 is now available The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org. GHC 9.14 will bring a number of new features and improvements, including: * Significant improvements in specialisation: * The `SPECIALISE` pragma now allows use of type application syntax * The `SPECIALISE` pragma can be used to specialise for expression arguments as well as type arguments. * Specialisation is now considerably more reliable in the presence of `newtype`s * the specialiser is now able to produce specialisations with polymorphic typeclass constraints, considerably broadening its scope. * Significant improvements in the GHCi debugger * Record fields can be defined to be non-linear when `LinearTypes` is enabled. * `RequiredTypeArgments` can now be used in more contexts * SSE/AVX support in the x86 native code generator backend * A major update of the Windows toolchain * ... and many more A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads. Due to unexpected complications, this initial prerelease comes a bit later than expected. Consequently, we expect to have three condensed alphas prior to the release candidate. We expect the next alpha will come the week of 9 Sept. 2025, while the third will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025. We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, SimSpace, the 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.

19.08.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Cabal 3.16 release The Cabal release team brings you a new release of the cabal-install tool and accompanying libraries, version 3.16.0.0. This release supports the (not yet available) GHC 9.14, including its upcoming alpha. We expect to publish cabal-install 3.16.1.0 soon after GHC 9.14 is out and address any discovered issues and incompatibilities that can be fixed in the respective timeframe. The binaries for cabal-install are available: * In the GHCup main channel (we thank the GHCup maintainers for the swift support of our release). * On our website (the same set of binaries can also be installed via the GHCup vanilla channel); these binaries are signed by "Francesco Ariis francesco@ariis.it" (fingerprint: `DAFB 4D8A F684 1435 18D5 051F A9AF 0AAA 6B87 EC51`; the key is hosted on keyserver.ubuntu.com). * As usual, `cabal update && cabal install cabal-install-3.16.0.0` is an option too. ### What's new Some of the cool features in the release: * The new `cabal target` command; * Faster Git clones; * `cabal haddock-project` handles user-provided CSS; * Multiple `flags` stanzas in `cabal.project` accumulate values instead of using the last one; * `cabal gen-bounds` works with multi-package projects (i.e., embraces the `v2`-commands infrastructure); * Cabal multi-repl supports reexported-modules with renaming for GHC >= 9.12, and more! See the cabal-install release notes on Github for the full changelog. Power users may be interested in Cabal-the-library notes too. ### 3.16.0.0 Contributors The credits go to: Andreas Abel, Andreas Klebinger, Artem Pelenitsyn, Benjamin, Benjamin McRae, Berk Özkütük, Bodigrim, brandon s allbery kf8nh, Bryan Richter, Francesco Ariis, Francesco Gazzetta, Gleb Popov, Hécate Moonlight, James Blackburn, Jaro, Jasper Van der Jeugt, Javier Sagredo, Jens Petersen, Kazu Yamamoto, Kevin Quick, Leonid Znamenok, malteneuss, Matthew Pickering, Matt Parsons, Mike Pilgrem, Mikolaj Konarski, Moritz Angermann, noiioiu, parsonsmatt, Peter Becich, Phil de Joux, PHO, Praneya Kumar, Rebecca Turner, Rodrigo Mesquita, Sdywolf, Serge S. Gulin, Sergey Vinokurov, sheaf, Sylvain Henry, Teo Camarasu, theGhostJW, Tom Smeding, Trevis, Troels Henriksen, Yi Fang, Yuto Takano, zlonast, Zubin Duggal. We thank all the contributors as well as our reviewers, QA testers, devops, and others without whom this release wouldn’t be possible. ### Feedback Please report any issues you notice with the 3.16.0.0 release on our GitHub: https://github.com/haskell/cabal/issues — Cabal release team (Artem, Brandon, Francesco, Mikołaj)

24.07.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

GHC LTS Releases # GHC will start maintaining an LTS release/branch in the near future A release being designated LTS (Long Term Support) in this case means we plan to support it over a longer timeframe than usual. Concretely the plan is to provide updates for a LTS releases for _at least_ two years. Most likely we will support LTS releases for even longer than that, aiming for a support window of three years currently. During this time we will be providing minor releases fixing bugs as with any other release. The main difference being that we will do so for a longer period of time. There are no plans to backport any new features to LTS releases after their initial release. In terms of frequency of LTS releases we plan to have an overlap between LTS support windows of different LTS series of six months. A potential timeline might then look like this: 2025 Aug - LTS 9.14 released 2028 Spring - LTS 9.22 released 2028 Summer - LTS 9.14.X - last 9.14 point release 2031 Spring - LTS 9.X released 2031 Summer - Last 9.22 point release … # Non-LTS releases GHC will continue to release new major non-lts releases on a ~6 Month cadence. We expect to cut back on the lifetime of these releases slightly, dedicating the resources freed up this way to enable a longer support window for the LTS releases. # Why LTS releases? In practice some releases always saw more adoption than others by users. The GHC Team has not been blind to this fact and has at times informally extended the life of a certain release based on this as well. This resulted in a sort of informal "post-hoc LTS" status of releases. At times with support windows not much shorter than our proposed minimum of two years. This worked reasonable well for people who were confident to stay on a fairly old release, only upgrading to a newer "post-hoc LTS" once the dust settled. It also worked out for those who picked one of those "post-hoc LTS" releases by happenstance before it was clear the release would end up as "post-hoc LTS". However users who adopted major releases which did not end up as "post-hoc LTS" often had to choose between upgrading earlier than expected, or risk running into a show stopping bug after the support window of the release had already ended. Similarly much of this was based on informal community sentiment and rarely written down explicitly. Making this information hard to access for members not deeply involved in the day to day of the haskell community. By designating a major release as LTS ahead of time we hope that users can make a informed decision about which GHC version they pick. Making it clear what the tradeoffs will be. With a clear choice between a longer support window or the newest features. # Why not make post-hoc LTS releases official instead? This is a question that has come up a lot in discussion. The major downsides of this are a lack of predictability, and that a lot of time might be lost between the initial release and any such decision. If we declare a release as LTS 9 months after its .1 release we essentially shaved off months from the LTS support window. On the flip side if we announce it ahead of time everyone knows that a given release will be the new LTS. So the hope is that this encourages more and quicker support for the release by the community. Hopefully compressing the timeline of bug fixing, testing and eventual widespread adoption. Overall I'm hopeful that LTS releases being explicit will remove a lot of ambiguity around GHC versions. And while the guaranteed LTS support window might not be as long as one might hope having LTS releases with longer guaranteed support window should still be helpful to people working on long running haskell projects. # Next steps The first LTS release will be GHC 9.14, which will be released this summer!

07.07.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Latest posts by blog.haskell.org.web.brid.gy on Bluesky