doing the painful thing less frequently doesn’t improve stability. we should be asking “why is it painful? how can we improve those things?” deferring the pain makes it worse, not better – you’re taking on a larger change, after all.
I strongly agree with this. Slowing down seems unlikely to help. I think there are quite a selection of different problems depending who you are, and the remedy may be different. @hasufell has a good list.
GHCUp/Stack/Stackage/Cabal/HLS
Mostly per-release busy-work where it doesn’t matter so much whether it’s a major or minor one. Sometimes tricky code changes, but indeed perhaps better to front-load these. HLS has a lot of dependencies, so it’s also has some of the “library developer” problems.
Library developers and hackage trustees (upper bounds, breaking changes, etc)
My belief is that almost all of this is about library changes, not changes to GHC the compiler. So the thing I’m excited about here is the ongoing work to decouple the version of base
(and template-haskell
) from GHC.
application developers
Here I think the question is mostly “do my dependencies work?” (previous point), and “is the compiler buggy?”. The fact that a lot of the major compiler versions are buggy is definitely a problem. Here I do think we could benefit from having LTS compiler versions. Empirically, it seems to take a while to find all the bugs and backport fixes: LTS versions give time for that process to happen. It’s not just us - it’s true for the Linux kernel as well!
This might also help with the amount of release work for GHC devs. If people mostly care about backports to the LTS branch, perhaps you can get away with having fewer active releases.
In addition, we have significant mental/decision overhead now regarding the question “which GHC branch should I pick?”.
Again, a LTS compiler would help with this.
Perhaps “frequent releases + LTS” is in practice similar to “infrequent releases + nightlies”. Personally I think the former is a bit easier to understand.