Feedback on potential change in boot library

Wed Nov 27 18:59:51 UTC 2024

On 27.11.2024 20.49, Oleg Grenrus wrote:
>
>
> 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.
>
I forgot to say, that if clients are not insensitive to additions to the 
API, i.e. they do use open imports, the PVP dictates to use strict bounds:

4. Client specification. Hence A.B.C uniquely identifies the API. A 
client that wants to specify that they depend on a particular version of 
the API can specify a particular A.B.C and be sure of getting that API 
only. For example, build-depends: mypkg >= 2.1.1 && < 2.1.2.

which no-one does, but that's their fault.

I'd argue that a design mistake in Haskell. We should not have open 
imports, nor implicit Prelude. The default thing (import Foo) does the 
wrong thing. Compare to Rust where "use foo" isn't a wildcard import. 
https://www.lurklurk.org/effective-rust/wildcard.html

>
>> 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
>
> _______________________________________________
> 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/69c5b646/attachment.html>