<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 27.11.2024 20.21, Ben Gamari wrote:<br>
</div>
<blockquote type="cite" cite="mid:87mshktu5l.fsf@smart-cactus.org">
<pre class="moz-quote-pre" wrap="">"Sebastian Graf" <a class="moz-txt-link-rfc2396E" href="mailto:sgraf1337@gmail.com"><sgraf1337@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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</pre>
</blockquote>
<p>PVP suggest to use qualified or explicit import lists.<br>
<a class="moz-txt-link-freetext" href="https://wiki.haskell.org/Import_modules_properly">https://wiki.haskell.org/Import_modules_properly</a><br>
<br>
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."<br>
<br>
That's right where in the PVP: <a class="moz-txt-link-freetext" href="https://pvp.haskell.org/">https://pvp.haskell.org/</a> point 5.<br>
<br>
<span style="white-space: pre-wrap">
</span></p>
<blockquote type="cite" cite="mid:87mshktu5l.fsf@smart-cactus.org">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<p>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".<br>
<br>
But in addition to that, PVP is contract between library authors
and consumers. It also says how consumer should specify their
dependencies.<br>
BOTH have to do their parts, if consumers don't follow PVP, it's
irrelevant what library authors do.<br>
<br>
"The goal of a versioning system is to inform clients of a package
of changes to that package that might affect them,<br>
and to provide a way for clients to specify a particular version
or range of versions of a dependency that they are compatible
with."<br>
<br>
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.<br>
<br>
* Semantic as in "assigns semantics to version number changes".<br>
<br>
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).<br>
<br>
So to repeat: if clients don't care to specify their compatibility
correctly, have courage to say it's their fault their code broke.<br>
<br>
</p>
<blockquote type="cite" cite="mid:87mshktu5l.fsf@smart-cactus.org">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</body>
</html>