Rusty SemVer parsing

[LemmaEOF]

Fabric as an ecosystem is generally cross-version compatible - as long as Minecraft doesn't make breaking changes, Fabric won't either. This ethos extends to all major APIs and libraries in the ecosystem, and we use SemVer to express this. However, people tend to write their dependencies in fabric.mod.json in a way that ends up hard-depping on exact Minecraft or Fabric versions without meaning to. SemVer expansion flags are hard to understand, especially for new users. Some other ecosystems, like Rust, work around this by assuming leniency over rigidity.

Currently, Fabric's SemVer implementation assumes that a version of, say, 1.2.3 in a dependencies block should be expanded to =1.2.3, meaning that 1.2.4 would fail to satisfy. The mod dev would probably be fine with any patch beyond 1.2.3, but expressing that without allowing patches lower than 1.2.3 or greater than 1.2.x is unintuitive. Rust solves this by instead assuming that 1.2.3 should be expanded to ^1.2.3, allowing reasonably safe upwards flexibility. Fabric is focused on being user-friendly and accessible to beginners, so designing leniency into the core architecture would be a good move.

[Earthcomputer]

I think that maybe 1.2.3 should mean any 1.x version that is greater than or equal to 1.2.3. When the major version is bumped, that means a breaking change, so the mod dev should have to explicitly say that breaking change is okay.

The one exception should be the minecraft dependency, where technically breaking changes happen all the time, but usually mods mostly break once the minor version is bumped. So 1.16.2 should mean any 1.16.x version that is greater than or equal to 1.16.2, since most mods are likely to break in some way by 1.17.