| 22 Apr 2025 |
 alexfmpe | https://github.com/commercialhaskell/stackage/blob/master/build-constraints.yaml#L8694 | 12:49:08 |
| alexfmpe | Oh heh TIL they also have our silly test-suite-induced-cycle issues | 12:50:33 |
 emily | FWIW, AIUI we used to track Stackage nightly but then stopped. it came up a while ago. I think maralorn had things to say about it. | 12:55:17 |
 maralorn | I am in favor of tracking nightly. We simply didn’t have the energy to frontload the flag day. | 12:59:57 |
| emily | is the flag day b/c jumping from current LTS to current nightly will effectively be the work of an LTS bump? | 13:01:09 |
| alexfmpe | I assume that becomes closer to the truth the closer nightly is to become new LTS? | 13:06:06 |
| alexfmpe | Or is nightly just very much broken in the early days? | 13:08:44 |
| maralorn | Its comparable yes. | 13:13:41 |
| maralorn | It’s often quite a lot smaller than LTS in the beginning. | 13:14:07 |
| emily | and I assume the current Nightly is closer to the next LTS than the one we just bumped to? 😆 | 13:14:33 |
| maralorn | correct | 13:15:57 |
| maralorn | Bumping the stackage snapshot generally means bumping the ghc major version that has friction no matter how early or late we do it. | 13:16:41 |
| alexfmpe | In reply to @maralorn:maralorn.de
It’s often quite a lot smaller than LTS in the beginning. Huh smaller building set or smaller breakage when bumping to it? | 13:19:55 |
| emily | I assumed the former | 13:23:27 |
| alexfmpe | Huh yeah the other doesn't make much sense disregarf | 13:26:13 |
| alexfmpe | * Huh yeah the other doesn't make much sense disregard | 13:26:21 |
| emily | right, I actually first assumed the latter and then realized it must be the former :) | 13:27:21 |
| 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 |
 sterni (he/him) | https://www.stackage.org/diff/lts-23.19/nightly-2025-04-22 looks like it would be a big pain upgrading at the moment with even more patching | 14:32:48 |
| alexfmpe | y'know, I wonder if our ghc-default+0.2 package set ends up out-building nightly | 14:34:52 |
| alexfmpe | just due to our sheer mass of overrides | 14:35:05 |
| alexfmpe | heck, we have reflex-dom and miso building with +0.4, and the former is pretty heavy dependency wise | 14:36:07 |
| alexfmpe | yeah a lot of packages will have older versions, but so many more actually build | 14:38:01 |
