[Metacello]: Loosen XMLParser Dependency

[seandenigris]

This was causing conflicts that may be unnecessary, as reported on the Pharo discord:

XML-XPath declares its dependency to XML-XMLParser as follows: github://pharo-contributions/XML-XMLParser:v3.6.x/src. This causes a conflict with Soup, which declares it this way: github://pharo-contributions/XML-XMLParser. This seems to necessitate special handling to load any project that depends on both. What's the best solution here? Remove the 3.6.x from one? Add it to the other? Something else?...

@dalehenrich suggested on the Metacello list to ask the person who set the version depended on by XPath if there's a particular reason to keep it. @astares it seems that was you (3d454ba). As far as you know, should it be safe to just depend on the baseline (i.e. remove the tag)?

Let's see if the tests pass pending an answer from @astares

[astares]

@seandenigris
Let me explain how it is supposed to work:

XML-XPath is declaring the dependency not on a explicit and specific version (like v3.6.1) but onto a "floating tag"
like v3.6.x. So depending onto which concrete release (typically the latest) it "flows" within the v.3.6.x release family
you might get XML-XMLParser v3.6.1 or as it is now v3.6.2. If in the future there is a release v3.6.3 we set the "floating tag"
v3.6.x to the same commit.

So we follow semantic versioning with MAJOR.MINOR.PATCH and with the additional "floating tag" allow for compatible "hotfixing" within the v3.6.x stream of versions without having every project who uses XML-XMLParser to adopt for every new release. So with this we can move/bugfix - but also guarantee some kind of compatibility. Details can be followed in https://semver.org

If there is a "user project" using the Parser project it can decide if it wants to depend on
A) an explicit non-changing version (not even on patch level) it must choose an explicit version like v3.6.1
B) if it wants a stable version (but profit from patching) it can choose the floating label v3.6.x
C) if it just wants to load "some version" by not giving an actual tag and basically decide for "I dont f*** care"

With A one is in full control. With B you are in a balance between getting a stable version but also patches.

With C things can become extremely shaky and easily leading to loading a broken incompatible set of the projects.
We do not want that for users of XML-XPath but also not for users of XML-XMLParser.

If we would remove the tag and solely load the baseline the XML-XMLParser might move forward (and get some
new additions) that will break XML-XPath. Then users of XML-XPath would be in trouble and we would not even be in control or notice it.

So unfortunately it would not make sense to accept this PR as your solution is not really solving it.

How to move on

Having said that nonetheless the problem is of different nature: you have dependencies on different sides
now leading to a conflict in loaded versions.
While Soup is just loading Baseline and just is not caring if it loads a compatible or broken Parser version
the XPath project actually does.

Two options:

• adopt Soup to provide also loading of the "floating" version
• if I'm not mistaken Monticello has some API to steer which version to use in case of conflicts or ignore the conflict

[seandenigris]

The right thing here is not as clear to me so I'm not ready to close this. I'm well versed in semantic versioning, but the tradeoffs here don't seem justified IMHO. I tried to capture my doubts about the general best practice in this Pharo Dev post. In the mean time, at minimum, following semantic versioning while minimizing complication, I think we should track the major, not the minor, which will ensure backward compatibility with less maintenance cost.

To address your final bullet point, trying to deal with this using the Metacello scripting API is a nightmare because it is not easily accessible from SmalltalkCI and would have to be duplicated in every downstream user - a cascade of dominos