GHC 9.8

[endgame]

Tweak the Nix and the ede templates so that service definitions compile with GHC 9.8.

Regenerated services to follow in a separate PR.

@brendanhay We will need to add upper bounds to the existing 2.0 service definitions because they don't build with GHC 9.8. Do you have any tooling to help with this? Given the stuff already on main, this deserves a major release, but since there's so many packages to upload, it's probably worth batching it with a couple of additional fixes. Also, can you please add me to the maintainer group for the uploaded packages?

See also: https://gitlab.haskell.org/ghc/ghc/-/issues/24317
Fixes: #969

[brendanhay]

We will need to add upper bounds to the existing 2.0 service definitions

You mean the existing 2.0 libraries already uploaded to Hackage? No tooling for that unfortunately, everything died in the Bazel fire.

The extension itself could go also into each service library's cabal file under a if/ghc conditional to ensure forwards/backwards compat?

[endgame]

We will need to add upper bounds to the existing 2.0 service definitions

You mean the existing 2.0 libraries already uploaded to Hackage? No tooling for that unfortunately, everything died in the Bazel fire.

Yes, and potentially pre-2.0 service definitions also, because they won't compile with new GHC for the same reason. I will see if I can chase down some information about Hackage's APIs.

The extension itself could go also into each service library's cabal file under a if/ghc conditional to ensure forwards/backwards compat?

I'm not sure what you mean by this. If we declare {-# LANGUAGE DuplicateRecordFields #-} in the module for each product type as well as for Types.hs, we get code which works with both GHC >=9.8 as well as <9.8.

[brendanhay]

I'm not sure what you mean by this. If we declare {-# LANGUAGE DuplicateRecordFields #-} in the module for each product type as well as for Types.hs, we get code which works with both GHC >=9.8 as well as <9.8.

I misunderstood until I read the linked gitlab issue.

[Bodigrim]

We will need to add upper bounds to the existing 2.0 service definitions because they don't build with GHC 9.8. Do you have any tooling to help with this?

One can use hackage-cli to make batch revisions.

[ysangkok]

@endgame What is needed to progress on this issue?

[endgame]

The mass-revision is now done. Sorry for the delay..

[ysangkok]

@endgame I see that this is part of the 2.1 milestone, but there are many tickets left in that milestone. Stackage is planning to do LTS-23 very soon and it would be a shame if Amazonka wasn't included only because a release hadn't been made...

[endgame]

How much time do we have? It would be nice to do an RC round before we drop 300+ packages onto Stackage, and Amazonka itself has a bunch of checks we need to run before each release (see the issue template).

Another wrinkle: I don't actually have the Hackage rights to upload new versions. @brendanhay are you around and do you have enough time to do things only you can do, if we choose to cut a release?

[ysangkok]

I don't think the exact date has been chosen yet, but since the last LTS is from around new year's, the next one should theoretically go out next month unless GHC 9.6.6 is somehow delayed. But I don't really know for sure.