search

brendanhay / amazonka

A comprehensive Amazon Web Services SDK for Haskell.
https://amazonka.brendanhay.nz
Other
599 stars 227 forks source link

GHC 9.8 #972

Closed endgame closed 4 months ago

endgame commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 5 months ago

@endgame What is needed to progress on this issue?

endgame commented 4 months ago

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

ysangkok commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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.