{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib7womolk3w5fkmcckkzo2javzu46s4x323nuxj3ejy74kpapt5ke",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mgjwinp34bt2"
  },
  "path": "/t/fork-basement-as-baseplate/12415?page=4#post_81",
  "publishedAt": "2026-03-08T06:11:04.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "ah so here’s an interesting question:\n\nhackage revisions currently are done to adjust bounds. if a drop-in, strictly more compatible fork under a different name is created..does it merit downstream hackage revisions?\n\nhackage revisions are usually because the package author made a mistake. too strict of bounds.\n\nin this case, they made the mistake of coupling to vincent.\n\nin both cases, no harm is done to the end-user. they get a strictly more compatible thing where before they get a cabal-install error.\n\nlike if i make basement2, why can’t we do revisions to basement-depending libraries? we would if i did basement 2.0.0.0. absent versioning, all hackage versions could be implemented as global identifiers on hackage byconcatenating name and version. they are functionally the same thing\n\nwe obviously don’t want to step on vincent’s rights to the basement name. but does he have a right to freeze everyone downstream of him too? i assume\nthey don’t care about him but rather just want their packages to work for anyone trying to use them.",
  "title": "Fork `basement`? As `baseplate`?"
}