{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibyso5j57xcjqjzyfnoiyl23kghdqfc2wc2vmdgq7d2kuyomkxsmi",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mojjkxdalcr2"
  },
  "path": "/t/making-ghc-upgrades-easy/14279#post_5",
  "publishedAt": "2026-06-17T08:11:38.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "Find a new way of specifying compiler compatiblity · Issue #5 · well-typed/reinstallable-base · GitHub"
  ],
  "textContent": "jackdk:\n\n> A lot of people (myself regrettably included) have historically used `base` bounds as a proxy for “which GHC release is this package compatible with?”. What’s the best way to indicate this moving forward?\n\nThis is indeed a bit of a lingering question, with some more discussion here: Find a new way of specifying compiler compatiblity · Issue #5 · well-typed/reinstallable-base · GitHub\n\nIt is possible for a `.cabal` file to use conditionals that depend on GHC version, but that isn’t a perfect solution: it can’t be changed retrospectively via revisions, and it may accidentally cause problems for other compilers (e.g. MicroHS) if the constraints assume the use of GHC.\n\nIdeally, we would minimize changes to the semantics of existing language extensions, and would instead add new extensions. That way packages can use `other-extensions` in their `.cabal` file to indicate what they need in a declarative way, and (in principle) any compiler supporting those extensions should work. However, not all extensions are well-specified and there are sometimes bugs or compiler behaviour changes meaning packages need to express more fine-grained constraints. Perhaps we should have a notion of versioning for language extensions…",
  "title": "Making GHC upgrades easy"
}