As the comment in the file you changed says, we'll need to bump the docker image for CI as well

As a matter of policy, we don't do unmotivated version bumps; a git bisect takes longer when Stack needs to blow away its cache and rebuild the world every time a particular commit is crossed, so whatever benefit we get from bumping versions has to clear at least that annoyance threshold. What's the motivation for this one?

@rhendric that's not my experience that stack needs to blow away it's cache. You can try it yourself just start a new haskell project with stack and then change the resolver to some different LTS. Builds already done on a particular LTS will build fast. Do you have a test case to reproduce your scenario where stack throws away the cache?

Uh, new compiler means new compilation artifacts; there's no test case involved here, that's just how it works. Do you have a motivation for this or not?

@rhendric yes new compiler, new artifacts. That doesn't explain what you were saying about stack blowing away cache and git bisect.

The motivation is that purescript is now on a compiler from 2022 that's a year ago. Every year the 9.2.5 version will get a year older. Meanwhile improvements are made to GHC which purescript can not benefit from as long as it's stuck on 9.2.5. How many years would you wait before updating a dependency?

@rhendric yes new compiler, new artifacts. That doesn't explain what you were saying about stack blowing away cache and git bisect.

Right, so in a year or two when developers are on whatever the current GHC is, hunting down a regression with git bisect means rebuilding the world when traversing any commit that changes the GHC. If you've retained build artifacts from two years ago in your cache, I suppose you don't have to wait any extra time, but I don't plan on doing that.

How many years would you wait before updating a dependency?

On this project, indefinitely, unless something can't be supported anymore, there's a bug needs fixing, we want a feature from a newer version, or there's a measured performance improvement from which we want to benefit (or similar motivations; this isn't necessarily an exhaustive list). Otherwise, if it isn't broken, we don't fix it.

Previously:
#3990
#4449

Thanks Ryan!

Looking at the reasons not to do it:

First issue #4449
purefunctor mentions "can become a bit tedious" without any further explanation why.

Second issue #3990
hdgarrood mentions:

• "we need to make another release because some upstream dependency was updated and it no longer builds". CI already proved that purescript compiles and all tests run fine.
• "At least one of our dependencies (language-javascript) is pinned to a specific version". The pinning of language-javascript has not been changed. Other direct dependencies have also not been changed. Only the build tool was changed, but purescript was built succesfully.

For the bisect you would need somebody who only caches for the purescript project as caches are shared between all your haskell projects. And also needs to do a bisect that spans over 2 years. And also has not done a bisect recently. And then this waiting time is incured only ones until the next active removal of the cache (like an OS install).

Looking at the reasons to do it:

These are the improvements to be had for upgrading the GHC version:

• https://downloads.haskell.org/~ghc/9.2.6/docs/html/users_guide/9.2.6-notes.html
• https://downloads.haskell.org/~ghc/9.2.7/docs/html/users_guide/9.2.7-notes.html
• https://downloads.haskell.org/~ghc/9.2.8/docs/html/users_guide/9.2.8-notes.html

There could be further improvements in packages but i didn't look into that.

If it ain't broke, don't fix it is often with an implication that the attempted improvement is risky and might backfire. But no possible risks were stated. Backfiring is an overstatement on a one-off cache rebuild imo.

@flip111, I appreciate your willingness to get involved in PureScript's development. We aren't interested in this sort of contribution unless the version bump contributes to another goal. But if you would like to make a future contribution that fixes a bug or implements a feature, I look forward to reviewing and eventually merging it. Please let this PR be.