{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreictqbvptrvc2fvijqckxzjvy3h6wmb2c6y4yvlyo3vi3dk6eduzgi",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mnhj2vkdmkp2"
  },
  "path": "/t/looking-for-a-parsec-maintainer-to-assist-with-ghc-9-14-compatibility-is-this-package-still-actively-maintained/14191#post_5",
  "publishedAt": "2026-06-04T10:52:14.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "version on Hackage",
    "GitLab",
    "Bump base upper bound to < 4.24 for GHC 10.0 (15f8a710) · Commits · Glasgow...",
    "@wz1000"
  ],
  "textContent": "jonathanknowles:\n\n> Even though the `parsec-3.1.18.0` boot package bundled with GHC `9.14.1` was itself compiled against `base-4.22.0.0`, the version on Hackage (with an outdated upper bound on `base`) seems to cause dependency resolution failures for packages that transitively depend on `parsec-3.1.18.0` when building with GHC `9.14.1`.\n\nThis looks like an error in the GHC release process.\n\nGitLab\n\n### Bump base upper bound to < 4.24 for GHC 10.0 (15f8a710) · Commits · Glasgow...\n\nGHC mirror of the parsec package\n\n@wz1000 bumped this in the GHC submodules.\n\nI don’t know if there was any communication with the parsec maintainers, but GHC shipping with unreleased boot libs has been a recurring issue.",
  "title": "Looking for a parsec maintainer to assist with GHC 9.14 compatibility (is this package still actively maintained?)"
}