| 22 Apr 2025 |
 emily | anyway I guess returning to the actual original point that was raised, I do feel like things are always going to be inherently difficult on some level unless the practices of the Haskell ecosystem itself change. not sure maintainers of packages supporting older and older GHCs is the answer – back in the day I remember it rather painful and it feeling like a relief to be able to rip out an old version, though maybe there's less CPP these days. ideally GHC would make fewer gratuitous breaking changes or at least do them more gracefully… (though again I understand that it's not as bad as it used to be) | 13:29:14 |
 maralorn | We don’t need a lot of back-compat. Maintainers should imo support [Stackage LTS … Stackage Nightly … Hackage Head] | 13:31:15 |
|  Albert Larsan joined the room. | 13:45:27 |
 @malteneuss:matrix.org | If you have the time, could you post this idea to https://discourse.haskell.org/t/how-much-effort-does-backwards-compatibility-require-from-library-authors/11584/79 to further the discussion on this possible direction? (will get more credibility/attention coming from you) | 13:49:57 |
| maralorn | Left a short comment. | 14:09:27 |
| maralorn | This is of course in tension with ghcup keeping 9.6 the recommended ghc. | 14:10:14 |
 alexfmpe | don't see a new haskell-updates PR, guess we're focusing on fixing staging for now?
rebased staging into it for now, don't think it counts as breaking, but if we want this for 25.05, best not dump a mass rebuild late in the cycle? | 14:31:05 |
| alexfmpe | essentially this means you can use the js backend in nixpkgs for browser, not only node
I mean, technically you already can, but need to mess with intermediates | 14:32:33 |
