Improve handling of version ranges

[MattSturgeon]

When dealing with dependencies, we often need to specify version ranges.

• fabric uses semver version ranges, such as >=1.20.0
• forge uses maven version ranges, such as [1.20,)
• publisher uses version lists, such as [ "1.20.0", "1.20.1", "1.20.2", "1.20.3", "1.20.4" ]

Note: a version list can never be truly equivalent to a version range, especially an open-ended one.

It'd be nice if we could store all our dependency ranges in a single format, be it semver or maven ranges, or something else entirely. Then we can use some tool to convert to whatever format is required at build-time.

Notes

One gotcha I foresee is that the releases needing explicit lists will mean open-ended "greater than x" ranges won't fully work; we'd have to go back to old releases and manually mark them as compatible with new MC releases as they come out.

Another gotcha is that while MC versions are, not all projects use semver; we'd have to check whatever libs we use work ok with the version formats we need to support OR only use them for mc version ranges not all version ranges.

Resources

• official maven range syntax
• short article on pre-release gotchas, from a maven perspective
• semver range cheatsheet
• semver ranges article

Tools

• apache enforcer is a tool for enforcing maven ranges
• unified-range a python tool for dealing with version ranges in different formats
• semver4j java semver lib; supports ranges in various formats
• semver.version another java semver lib