[Loader Plugins] Allow loader plugins to define version schemes

[LambdAurora]

Pretty self-explanatory, once loader plugins are a thing, it would be nice if they could define new version schemes rather than forcing everyone to use semver as some people use either their own version schemes, or use other standards.

Saw that in the QMJ spec the loader should crash on non-semver versions, this seems to be a bit of a pointless holy war and would only cause trouble to mod developers in a way.

[TheGlitch76]

We absolutely have to support alternative version implementations in some capacity because Fabric and Forge don't enforce SemVer.

For mods being developed specifically for Quilt, what is a use case where a mod would not be able to use semantic versioning?

[LambdAurora]

We absolutely have to support alternative version implementations in some capacity because Fabric and Forge don't enforce SemVer.

For mods being developed specifically for Quilt, what is a use case where a mod would not be able to use semantic versioning?

For example, there is no clear way to do hotfixes in semver, I have seen some people doing <main version string>_01 for a first hotfix, which is not semver-compliant.

Now take the build metadata thing, it is said in the semver spec that build metadata does not change precedence, which means there's no clear way over which version of the mod should be picked with the hotfixes stuff.

[TheGlitch76]

For example, there is no clear way to do hotfixes in semver, I have seen some people doing <main version string>_01 for a first hotfix, which is not semver-compliant.

Now take the build metadata thing, it is said in the semver spec that build metadata does not change precedence, which means there's no clear way over which version of the mod should be picked with the hotfixes stuff.

For other people following this issue, here's a pretty good thread about this issue: semver/semver#241

The tl;dr is that the hotfix problem comes when you have a critical issue in 1.0.0, but 1.0.1 is going through a testing pipeline for one reason or another. Not really something that affects Minecraft mods 99% of the time, but it is a real issue with semver.

I'm personally going to think on this issue until we get further along with loader plugins--perhaps Fabric's weird many-component semver isn't that bad? If we allow arbitrary version implementations, how do we handle them comparing with each other? etc.

[LambdAurora]

I'm personally going to think on this issue until we get further along with loader plugins--perhaps Fabric's weird many-component semver isn't that bad? If we allow arbitrary version implementations, how do we handle them comparing with each other? etc.

To allow arbitrary version implementations, it would be required to have some kind of internal representation that every version schemes should be converted to to allow comparison in some ways I guess?

[AlexIIL]

Saw that in the QMJ spec the loader should crash on non-semver versions, this seems to be a bit of a pointless holy war and would only cause trouble to mod developers in a way.

Are you sure this is a question about loader plugins, and not a general request that the QMJ spec shouldn't mandate semver? I don't think loader plugins would be able to modify how quilt mods get loaded - so if you want to make a quilt mod that doesn't use semver, you'd need to modify the QMJ spec to allow that.

[Haven-King]

I think the key assumption that is mistakenly made here is that QMJ is the end result for all mods loaded by loader plugins. The QMJ spec dictates the restrictions of Quilt's loader plugin. Quilt Loader itself can use any kind of internal representation it wants. In the case of versions, a limitless length series of version numbers (such that 1.0.0 and 1.0.0.0.0.0.0.0.0.0.0 ... are both valid and comparable) would make the most sense to me. Each plugin would then be responsible for interpreting the version its mod uses and representing it as a series of numbers, from most significant to least significant.

[TheGlitch76]

We've implemented FlexVer as our one system for handling versions, which should be flexible enough (lol) to handle use cases which would be covered by this system.