Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Wispborne]

Apologies if you're already aware, wasn't sure quite what keywords to use to find an existing report.
Although this happens only in a modded game, it's caused by an issue in vanilla.

The documentation for the version field in mod_info.json says:
> A major version mismatch between the mod and another mod that depends on that version of it means the mod that depends on it can not be enabled. A minor/patch mismatch results in a warning.


That appears to only be the case if both mods use the longer Json object format; if either of them uses the older string format, the comparison doesn't work correctly.

I tested using Seeker and MagicLib.

If MagicLib's version is "0.45.2" and Seeker requires MagicLib version "0.42.0" then, theoretically, only a warning should be shown, as the minor version changed but not the major.
However, the game shows an error, not a warning, and doesn't allow Seeker to load.

But! If I change both of those to use the newer version schema: {"major":0, "minor":45, "patch":2} and {"major":0, "minor":42, "patch":0}
then behold, Seeker is shown with a warning but it is allowed to load, as it should be.

[Alex]

Ah - since the first value is zero, the from-string parser is assuming the major version is "0.45" and "0.42", respectively, and seeing a mismatch.

I don't remember why this is, but for some reason this (the starting-with "0.") case is specifically checked for. So I'm kind of hesitant to change this...

I can definitely see that this is weird/inconsistent behavior, though. Hmm. Just wondering, why in the heck I'd specifically do it that way. Either past-me wasn't thinking this through very well (which, definitely possible) or was trying to cover some existing use case (seems somewhat more likely? but not sure what it might be).

[Wispborne]

Gah. That thought crossed my mind and I dismissed it without testing.

My guess would be that in a pre-1.0 mod, every minor version could be considered a breaking change? And only after it hits 1.0 would it be more stable and you'd shift to major versions being breaking.

I actually just looked at SemVer and you're following it, basically. https://semver.org/spec/v2.0.0.html#spec-item-4
> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

So that's interesting and blows the root of my argument apart, since I really like SemVer. That said, it is still inconsistent between the two different json formats...

[Alex]

I actually just looked at SemVer and you're following it, basically.

(Probably unintentionally, if we're being completely honest.)


Wait, *two* json formats?

[Wispborne]

On phone now, but the two different ways to define a version. Using just a string vs using major/minor/patch object.
The comparison if both mods are using the 3 part object for the version (lib mod version and the version in another mod's Dependencies section) treats a major version of 0 as stable...it doesn't prevent the mod from loading of the minor version is different.

[Alex]

Ah, got it; I wasn't thinking of the "one strong" format as a json one, but yeah, I see what you mean.

The detailed format just lets you specify whatever string you want for each; I guess if the goal is to cleave to SemVer, then the issue would be with a mod choosing to specify a "wrong" major version given that approach...

[Wispborne]

This is what I should have led with: https://imgur.com/a/Bv73QGi

First pair shows that it is compatible using the long version format, second pair shows it as incompatible using the short version format, but in both cases the version itself is the same.