<!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.49, Oleg Grenrus
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:abe20ff5-191a-4259-8661-9a0254593300@iki.fi">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true"><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"
moz-do-not-send="true">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/" moz-do-not-send="true">https://pvp.haskell.org/</a>
point 5.<br>
</p>
</blockquote>
<p>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:<br>
<br>
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.<br>
</p>
<p>which no-one does, but that's their fault.<br>
<br>
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.
<a class="moz-txt-link-freetext" href="https://www.lurklurk.org/effective-rust/wildcard.html">https://www.lurklurk.org/effective-rust/wildcard.html</a><br>
</p>
<blockquote type="cite"
cite="mid:abe20ff5-191a-4259-8661-9a0254593300@iki.fi">
<p> <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">
<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 moz-txt-link-freetext"
href="mailto:ghc-devs@haskell.org" moz-do-not-send="true">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext"
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
<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>