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