Hackage should calculate GHC compatibility

[gbaz]

Given that we know the mapping of base bounds to ghc versions, we can probably compute a message for each package that indicates the likely GHC compatibility range. This should help clear up user confusion. Alternately or concomitantly, we could just have a more prominent link to the matrix.hackage server? (@hvr for comment on this).

[hvr]

we could just have a more prominent link to the matrix.hackage server?

that one we have already; we could make it more prominent though and I've already got some idea I need to mock-up...

[steve-chavez]

Can I pin the ghc version hackage chooses somehow? Recently, I had a failed build http://hackage.haskell.org/package/postgrest-0.5.0.0/reports/3 because I need the ghc version to be less than 8.4.2.

Limiting the base package will work?

[hvr]

@steve-chavez Well, as far as I can see from https://hackage.haskell.org/package/postgrest-0.5.0.0/dependencies has a severely underspecified dependency specification; you need to place version constraints on all your dependencies if you want your package to work properly as otherwise it will inevitably allow cabal to pick configurations which don't work properly (and if you're lucky those will result in compile failures; if you're unlucky it'll compile but behave incorrectly at runtime).

You can also take a look at https://matrix.hackage.haskell.org/package/postgrest which already shows the kind of build failures users of your package will likely run into.

As to your question for requesting the doc builder to use an older GHC version: currently the doc-builder supports only GHC 8.4.3; but constraining the allowed base versions is the current idiomatic way to signal by proxy which versions of GHC are supported.