Feedback on potential change in boot library

[Oleg Grenrus]

On 27.11.2024 20.21, Ben Gamari wrote:
> "Sebastian Graf"<sgraf1337 at gmail.com>  writes:
>
>> Hi,
>>
>> Do we have concrete evidence that minor bumps in a boot library have
>> caused breakage in the past? (That would of course be a bug in the boot
>> library according to the PVP.)
>>
> Yes, I cited two such examples that came to mind in the original
> message. These weren't hard to find, despite boot library bumps in GHC
> minor releases being historically rather rare.
>
> Contrary to what one might be tempted to conclude, PVP-compliant,
> non-buggy minor bumps can cause breakage for downstream users. The
> reason for this is typically the introduction of new exports. For
> instance, in #25411 we found that the bump of `deepseq` in 9.8.3
> introduced a new export (`Unit`) from `Control.DeepSeq`. This is, of
> course, a minor change under the PVP but renders previously working
> modules unbuildable due to ambiguous occurrences.
>
> Perhaps in an ideal world all `import`s would be either `qualified` or
> include an explicit import list but, sadly, this is not the world in

PVP suggest to use qualified or explicit import lists.
https://wiki.haskell.org/Import_modules_properly

Only then "A client MAY specify that they are insensitive to additions 
to the API by allowing a range of C values, e.g. build-depends: base >= 
2.1.1 && < 2.2."

That's right where in the PVP: https://pvp.haskell.org/ point 5.

> which we live. Consequently, the principle difference between a major
> and minor bump is that the breakage from the latter is usually "easy" to
> fix. However, it is breakage nevertheless and even easy breakage can
> cost significant time when migrating large code-bases.

No. PVP clearly says which kind of changes MUST be major bumps, which 
MUST be at least minor bumps etc. There is very little of "interpretation".

But in addition to that, PVP is contract between library authors and 
consumers. It also says how consumer should specify their dependencies.
BOTH have to do their parts, if consumers don't follow PVP, it's 
irrelevant what library authors do.

"The goal of a versioning system is to inform clients of a package of 
changes to that package that might affect them,
and to provide a way for clients to specify a particular version or 
range of versions of a dependency that they are compatible with."

Otherwise we can simply treat all changes as breaking changes and throw 
any semantic* version policy into a garbage bin. Make people read the 
changelogs.

* Semantic as in "assigns semantics to version number changes".

To make this even more concrete: Minor GHC releases couldn't bump minor 
`base` either. If GHC-9.12.1 ships with `base-4.21.0.0`, then will 
GHC-9.12.2 and later too. Significant amount of ecosystem does `base 
<5`, so it's arguable that we cannot introduce any (breaking) change, 
like removing modules from `base`, without going past version 5 (and 
before people start to do `base < 1000` bounds, which I think i have seen).

So to repeat: if clients don't care to specify their compatibility 
correctly, have courage to say it's their fault their code broke.

>> I would think that such breakage is even less of an issue for a new GHC
>> minor release (say GHC 9.8.4).
>> The hackage ecosystem is likely prepared to compile with the GHC 9.8
>> series at this point, so it should be possible to detect such breakages
>> by compiling stackage/hackage and running testsuites.
>>
> Indeed head.hackage identified the breakage in 9.8.3. However, we
> decided to move ahead regardless since the maintainer requested it.
> The policy proposed in the head of thread will make this sort of
> breakage considerably more likely to appear in future releases.
>
>> Besides, the only reliable way to prevent such breakage is not to bump
>> any boot library *at all*.
>> If a boot library breaks on a minor bump, it is just as likely that it
>> breaks on a super-minor bump.
>>
> I am not sure I agree. While the PVP is silent on this matter, IMHO
> patch-level bumps should not touch external interfaces at all, only
> implementation and packaging. This makes it much less likely for
> breakage to manifest.
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> 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/20241127/7de84cc4/attachment.html>