Feedback on potential change in boot library

[Moritz Angermann]

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 at gmail.com> wrote:

> On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs <
> ghc-devs at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241221/4680ade0/attachment.html>