I recently experienced some CI problems for several of my projects because of
an (IMO unnecessarily tight) version specification of XML-XPATH’s dependency on
XMLParser: \`github://pharo-contributions/XML-XMLParser:v3.6.x/src\`. At
minimum, it seems the dependency should be on the major version (e.g. v3), not
the minor (unless I’m missing a needed feature that was added in 3.6).
More importantly though, it raises questions about what the best practice is
here. In summary, it seems to me that in general it’s better to only pin
versions in reaction to CI failures because pinning has significant downsides
and uncertainties. Defensive pinning smells like premature optimization IMO.
In more detail, partially pinning (to major or minor version) *by default*
doesn't seem right to me for several reasons unless we're talking about a
tagged release that should be reproducible because:
* We have limited community resources to manage these pinnings, which create
cascading conflict problems with all other dependent projects.
* Pinnings seem somewhat arbitrary because often community maintainers are not
familiar enough with both projects or have enough time to do a thorough
investigation. How does the maintainer know whether a particular dependency
version really “works” with the project? Unless they are intimately familiar
with both projects (and even then I wouldn’t have confidence in a manual
review), the best way I can think of is to rely on passing CI, and in that
case…
* It seems easier to just react to CI failures; defensive pinning smells like
premature optimization IMO
* Partial pinning (minor or major version) will not lead to reproducible builds
because the patch is floating
* What does reproducibility even mean from an untagged baseline?
Looking through a bunch of repos, it doesn’t seem that there is consensus
either way. Some specify baselines and some specific versions.
p.s. for tracking the major, I like ba-st’s naming convention of v{integer}
instead of adding “.x”’s of unclear value
