Feedback on potential change in boot library

[Andreas Klebinger]

I searched for unqualified "import Data.Text" occurrences on hackage via
serokell code search and there are dozens of libraries with such an import.

We had a lot of complaints about far smaller breaks in backwards
compatibility in the past.
This does not mean we can't make bumps which cause such breakage, but we
need to at least properly consider the breakage it will cause.

Am 21/12/2024 um 15:02 schrieb Andrew Lelechenko:
> 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