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