See a typo? Have a suggestion? Edit this page on Github
I'm announcing a new, experimental field in the
build-constraints.yaml file for Stackage. For
those not familiar with Hackage revisions, let me give a quick rundown
of how things work:
When a Stackage build runs, until now it would always take the most recent revision of a .cabal file and use that for bounds checking (and other activities). Then, when creating a snapshot, it would include a hash of the revision of the .cabal file it used. That hash is in turn used by Stack to ensure that—when building a package from a snapshot—it uses the same revision for reproducibility.
(Sound complicated? It kind of is.)
OK, all that said: what's the problem? Well, there are some
disagreements in certain cases about whether a revision to a package's
.cabal file should have occurred. An unwanted revision can create
undesired work for the package author. After this situation arose a
few times, I discussed with some involved parties, and came up with
no-revisions field. Its purpose is really simple:
When the Stackage build tool is choosing which .cabal file revision to use, if a package is present in the
no-revisionslist, then the original revision is used. Otherwise, the newest revision is used.
UPDATE Someone pointed out that this "unwanted work" description was pretty vague. To clarify, here's an example situation:
foo, and depends on
bar >= 2.3(with no upper bounds). The latest version of
baron Hackage is 2.3.
bar >= 2.3 && < 2.4
foocode is compatible with
bar-2.4, so does nothing.
no-revisionsin place, Alice could initially put
no-revisionslist, and then Bob's changes would be ignored completely by Stackage.
This is an opt-in field, so people who want the current behavior need not do anything. This change will transparently work for Stack, since it will simply respect the hash of the .cabal file. And since there may be some negative ramifications of this change I haven't considered, I'm calling this feature experimental and asking for feedback if this causing anyone some issues.
Hopefully this change will let people who are using the Stack and Stackage toolchain work with less interference, with less friction occurring with Hackage Trustees making version bounds modifications.