I’m mildly concerned about the show export. However the real issue is that we have no good way to measure the actual impact of this change. I believe text to be reinstallable and as such unless GHC prohibits a downgrade of text end users could still use an older non-breaking text. I’m much less concerned about boot library bumps that do not force these version on an end user without the ability to override and downgrade. The goal must always be to be able to use a newer compiler with an existing codebase outright. Anything else is just a recipe for QA disaster. On Sat, Dec 21, 2024 at 11:02 PM Andrew Lelechenko < andrew.lelechenko@gmail.com> wrote:

On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs < ghc-devs@haskell.org> wrote:

...

For example we should probably not upgrade point releases from text-2.1.1 to text-2.1.2 as the addition of `show` causes breakage and there seem to be no bug fixes in the release, unless the library authors request us to do so.

There are quite a few bug fixes in text-2.1.2 actually, e. g., fixing the atomicity of putStrLn which is quite a significant improvement. I struggle to see how addition of `Data.Text.show` can break much, given that `Data.Text` is almost universally imported qualified.

Returning to the original question, I’m in favour of bumping boot libraries aggressively. From the perspective of boot libraries maintainers other arrangements are both discouraging and detrimental for quality. If the only way to get feedback for a new release of, say, `bytestring` is to wait 6 months until the next major release of GHC and then wait until a new GHC gains a significant traction, then we are doomed to have bugs lurking forever. And it’s also hugely unsatisfying to spend lots of work on a new release, knowing that an average user would not benefit from it in the next few years.

It could make sense to have a stricter policy when releasing a last-in-series GHC, where cost of introducing new bugs / incompatibilities is much higher (because it entails making an otherwise unplanned release). But for mid-series releases I’d recommend bumping minor versions of boot libraries as soon as possible.

Best regards, Andrew _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs