November 2024 - ghc-releases

GHC 9.8.4 release status
by Ben Gamari 02 Dec '24

02 Dec '24

Hi all, After several false-starts, I believe we now have a candidate pipeline [1] for the 9.8.4 release. This includes bumps to the unix and filepath submodules, a few compiler correctness fixes, and some documentation packaging improvements. Do let me know if there are any questions or concerns, otherwise I will move ahead with release mid-next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/pipelines/103556

2 4

[ANNOUNCE] GHC 9.12.1-rc1 is now available
by Zubin Duggal 29 Nov '24

29 Nov '24

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * ... and many more A full accounting of changes 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 GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, 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. Cheers, Zubin [release notes]: https://downloads.haskell.org/ghc/9.12.1-rc1/docs/users_guide/9.12.1-notes.… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e…

1 0

Re: [GHC-Releases] Feedback on potential change in boot library
by Sebastian Graf 27 Nov '24

27 Nov '24

Hi, Do we have concrete evidence that minor bumps in a boot library have caused breakage in the past? (That would of course be a bug in the boot library according to the PVP.) I would think that such breakage is even less of an issue for a new GHC minor release (say GHC 9.8.4). The hackage ecosystem is likely prepared to compile with the GHC 9.8 series at this point, so it should be possible to detect such breakages by compiling stackage/hackage and running testsuites. That is, I would think it is harder to anticipate unforeseen boot library breakage for a new major release of GHC than it is to anticipate breakage for a minor GHC release. Besides, the only reliable way to prevent such breakage is not to bump any boot library *at all*. If a boot library breaks on a minor bump, it is just as likely that it breaks on a super-minor bump. So bumping minor versions of boot library sounds reasonable to me, barring concrete evidence that minor bumps have caused problems in the past (which again means there was a bug in a boot library). Sebastian ------ Originalnachricht ------ Von "Tom Ellis" <tom-lists-haskell-cafe-2023(a)jaguarpaw.co.uk> An ghc-devs(a)haskell.org Datum 27.11.2024 10:57:57 Betreff Re: Feedback on potential change in boot library >Thanks Adam, > >I'm not too familiar with the GHC-side requirements here, but I wonder >if we can approach this issue from a different direction: is there >something we can do to help boot libraries avoid breaking changes? > >Tom > > >On Wed, Nov 27, 2024 at 08:02:10AM +0000, Adam Gundry wrote: >> It's not obvious to me that this is a good idea. Users already complain that >> "upgrading GHC broke my code", when in practice this frequently means "when >> upgrading GHC I used new boot library versions with incompatible APIs that >> broke my code". So having a policy of introducing more frequent API changes >> (and making it harder to switch between GHC releases in a single release >> series) needs clear justification IMHO. >> >> (Of course in the long term we should make it easier for users to pin boot >> library APIs while upgrading GHC independently, but we're not there yet.) >> >> I think that by default, it makes sense for a new minor GHC release to keep >> the same API versions of boot libraries, but bump to the latest super-minor >> component (i.e. for an A.B.C.D version, keep A.B.C the same but bump D). If >> a boot library fixes a bug that is critical enough to require bumping the >> version distributed with GHC, ideally there would be an API-compatible >> release of the boot library. Of course that might not always be feasible, >> and it is ultimately a judgement call for the GHC maintainers as to which >> boot library versions are best to ship. >> >> On 26/11/2024 22:27, Hécate via ghc-devs wrote: >> > From the cabal perspective this great news, as this will allow the >> > feedback cycle between our two projects to be shorter. Glad to see the >> > GHC team is considering this! >> > >> > Cheers, >> > Hécate >> > >> > Le 26/11/2024 à 21:14, Ben Gamari a écrit : >> > > tl;dr. We propose that GHC more aggressively bump its boot library >> > > dependencies. >> > > >> > > >> > > Hello all, >> > > >> > > Historically, GHC minor releases have been quite conservative in bumping >> > > boot library versions, generally defaulting to retaining the versions >> > > used in the GHC-x.y.1 release unless >> > > >> > > * a request is made by a boot library maintainer, or >> > > * we discover an issue which warrants a bump >> > > >> > > The motivation for this policy is both to >> > > >> > > * minimize the potential for regressions in correctness and >> > > performance, and >> > > >> > > * reduce the potential for end-user breakage due to interface changes >> > > as even minor releases can result in considerable impact (e.g. >> > > #25411, #22633) >> > > >> > > While this policy has served us well, its conservative nature demands >> > > the vigilence of both GHC and upstream maintainers to ensure that bumps >> > > that are truly necessary do not fall through the cracks. >> > > >> > > As the flaws of this process have been more apparent recently (e.g. >> > > #24597), we have done a bit of reflection on how we might improve the >> > > status quo. Concretely, I would like feedback on the adopting the >> > > following policy going forward: >> > > >> > > > Unless guidance is provided otherwise by a library maintainer, a GHC >> > > > x.y.z release will attempt to ship the newest minor version of each >> > > > boot libray in the same major series shipped with GHC x.y.1. >> > > I believe this policy would leave less room for human error and open >> > > opportunities for automated checking. On the other hand, the more >> > > aggressive bumping of submodules may mean that users are hit with more >> > > (usually minor) compatibility issues when moving between minor GHC >> > > releases. >> > > >> > > How do others feel about this? We are particularly interested to hear >> > > from boot library maintainers but feedback from packagers and users is >> > > also very much welcome. >_______________________________________________ >ghc-devs mailing list >ghc-devs(a)haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

GHC 9.12.1 updates and rc1 status
by Zubin Duggal 27 Nov '24

27 Nov '24

Hi all, We had planned to release 9.12.1-rc1 today. Unfortunately, we discovered a few regressions and bugs which need to be fixed before we can publish a release candidate, including #25382, #25375 and !13633. I am currently waiting for some of these fixes to land in master before backporting them to the release branch. I will try to have the release candidate out on Monday the 25th. The final release is currently scheduled for December 6th. We will inform you if there are any changes to this schedule. Cheers, Zubin.

1 1

Feedback on potential change in boot library
by Ben Gamari 26 Nov '24

26 Nov '24

tl;dr. We propose that GHC more aggressively bump its boot library dependencies. Hello all, Historically, GHC minor releases have been quite conservative in bumping boot library versions, generally defaulting to retaining the versions used in the GHC-x.y.1 release unless * a request is made by a boot library maintainer, or * we discover an issue which warrants a bump The motivation for this policy is both to * minimize the potential for regressions in correctness and performance, and * reduce the potential for end-user breakage due to interface changes as even minor releases can result in considerable impact (e.g. #25411, #22633) While this policy has served us well, its conservative nature demands the vigilence of both GHC and upstream maintainers to ensure that bumps that are truly necessary do not fall through the cracks. As the flaws of this process have been more apparent recently (e.g. #24597), we have done a bit of reflection on how we might improve the status quo. Concretely, I would like feedback on the adopting the following policy going forward: > Unless guidance is provided otherwise by a library maintainer, a GHC > x.y.z release will attempt to ship the newest minor version of each > boot libray in the same major series shipped with GHC x.y.1. I believe this policy would leave less room for human error and open opportunities for automated checking. On the other hand, the more aggressive bumping of submodules may mean that users are hit with more (usually minor) compatibility issues when moving between minor GHC releases. How do others feel about this? We are particularly interested to hear from boot library maintainers but feedback from packagers and users is also very much welcome. Cheers, - Ben

1 0

GHC 9.8.4 release status
by Ben Gamari 20 Nov '24

20 Nov '24

Hi all, The penultimate release pipeline for 9.8.4 can be found at [0]. Unfortunately, it is affected by a non-user-facing Hadrian issue compromising one of the validation jobs. I have pushed a commit fixing this and have started a new pipeline [1]. Consequently, I wanted to inform downstreams that we are quickly closing in on the final 9.8.4 release. I believe this release has addressed all of the packaging concerns with 9.8.3 including: * manpages are now included in all jobs save CentOS 7. I am attempting [2] to enable Sphinx output on CentOS 7 as well, although there is a significant chance that this will fail due to the old Sphinx version shipped on that platform. If so I suggest that we cut our losses on documentation on CentOS 7; 9.8.4 will already be considerably better in this regard than previous releases in the series. * `filepath` has been bumped to 1.4.301.0 * `unix` has been bumped to 2.8.6.0 As well, I have included two bug-fixes to significant compiler correctness bugs. If anyone has any concerns, please do share them now so we can move ahead with finalizing the release. Cheers, - Ben [0] https://gitlab.haskell.org/ghc/ghc/-/pipelines/103460 [1] https://gitlab.haskell.org/ghc/ghc/-/pipelines/103472 [2] https://gitlab.haskell.org/ghc/ghc/-/pipelines/103475

1 0

GHC 9.8.4
by Ben Gamari 17 Nov '24

17 Nov '24

Hi all, In light of the various issues reported in 9.8.3, I have prepared a 9.8.4 release. What is likely to be the final release pipeline can be found here [1]. However, before moving ahead with the release process, I would like to confirm that this release covers the issues raised with 9.8.3; specifically: * we ship with filepath-1.4.300.2 * we provide manpages in all binary distributions In addition, I backported two unrelated fixes (a soundness fix related to prompt# and a fix affecting -Wmissing-home-modules). Julian, perhaps you could confirm that this addresses your concerns? Cheers, - Ben

2 4

[ANNOUNCE] GHC 9.12.1-alpha3 is now available
by Zubin Duggal 15 Nov '24

15 Nov '24

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * ... and many more A full accounting of changes 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 GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, 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. [release notes]: https://downloads.haskell.org/ghc/9.12.1-alpha3/docs/users_guide/9.12.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1-alpha3 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e… Cheers, Zubin

1 0

GHC 9.12 release schedule and submodule status
by Zubin Duggal 12 Nov '24

12 Nov '24

Hi all, (This is a resend of an email I sent a short while ago. I seem to have messed up some email headers that might trip up some filters so I'm resending it to be safe. You only need to read one of these if you recieved my previous email) I'm writing to your in your role as a maintainer of one of the GHC boot packages. This is an update on the 9.12 release schedule. We plan to have the release out by the end of the month (ideally on 29/11/24), with an alpha/rc every week from now until the release is finalised: | Date | Event | | ----------------- | -------- | | Nov 15 2024 | alpha 3 | | Nov 22 2024 | release candidate | | Nov 29 2024 | final | Additionally, this is the final call for any submodule bumps that may be desired. The current status of the submodules is described in this spreadsheet, under the GHC 9.12 tab: https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG… If any version that is not listed in the spreadsheet is desired, please notify me and ensure that a release is tagged and uploaded to hackage as soon as possible. I would like to finalise the state of submodules by the first release candidate. This email is individually addressed to the maintainers of all the boot libraries, as best as we could collate such a list. If you are aware of any changes to the list of GHC boot packages maintainers, please let us know. We aim to have a more systematic process for such communications with library maintainers for releases in the future. Once we finalise such a process we will let you know. Thanks for all your work, Zubin.

2 1

GHC 9.12 release schedule and submodule status
by Zubin Duggal 11 Nov '24

11 Nov '24

Cc Bcc: Subject: 9.12 schedule and submodule status Hi all, I'm writing to your in your role as a maintainer of one of the GHC boot packages. This is an update on the 9.12 release schedule. We plan to have the release out by the end of the month (ideally on 29/11/24), with an alpha/rc every week from now until the release is finalised: | Date | Event | | ----------------- | -------- | | Nov 15 2024 | alpha 3 | | Nov 22 2024 | release candidate | | Nov 29 2024 | final | Additionally, this is the final call for any submodule bumps that may be desired. The current status of the submodules is described in this spreadsheet, under the GHC 9.12 tab: https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG… If any version that is not listed in the spreadsheet is desired, please notify me and ensure that a release is tagged and uploaded to hackage as soon as possible. I would like to finalise the state of submodules by the first release candidate. This email is individually addressed to the maintainers of all the boot libraries, as best as we could collate such a list. If you are aware of any changes to the list of GHC boot packages maintainers, please let us know. We aim to have a more systematic process for such communications with library maintainers for releases in the future. Once we finalise such a process we will let you know. Thanks for all your work, Zubin.

1 0