[FEATURE REQUEST] - Modpack Version Enforcement

[KairuByte]

What problem does the feature request solve? Some mods are version sensitive between server and client. Meaning that installing an update to the client before the server has been updated can cause a client to not properly connect. This feature would allow setting a flag which locks the version of all mods to the specific version in the dependency, and prevent upgrade alerts for all but the modpack.

Example mock-up (optional) Let's set up a hypothetical Valheim server with NotARealMod v1.2. NotARealMod is very particular about its version comparability, so neither v1.1 nor the released-seconds-ago v2.0 are compatible.

However, when User1 loads up r2modman, they see a new update and immediately install it. However the server owner hasn't had the chance, since it's literally been seconds. The user is then unable to connect and play.

If instead, the player was never presented with the update because the only update check being performed was on the modpack, the problem would have never presented itself.

Additional information (optional) While this seems like something you can just teach players to handle on their own, there is a subset that just always update everything, then get confused when things go awry. Locking down the version to the versions specified in the modpack would solve this problem.

[ebkr]

This is something that is done but requires you to apply the modpack tag on Thunderstore when uploading

[KairuByte]

That feature is semi related but different.

While dependencies get installed to the specified version, they do not stay at that version. Updates to dependencies are still alerted on, and no warning is given that they are moving off the modpack required version.

This suggestion would essentially remove the UI update aspect for modpack dependencies completely, meaning that the only way to update the mods would be through a modpack update.

[ginsm]

Any update on this? 🤔 I use the Modpacks tag/category but as Kairu said, users are still able to update the modpack dependencies freely which means they become out of sync with the server.

[1RV34]

I would love to get version constraints capabilities, for example using "^1.2" which would be equivalent to ">=1.2.0 <2.0.0" It will require a version solver and might not always resolve to an installable set if different packs have conflicting constraints, but I rather be notified to update constraints than not having constraints at all.

Also to stay backwards compatible we could probably use a new property in the manifest like:

{
    "name": "...",
    "version_number": "...",
    "description": "...",
    "website_url": "...",
    "dependencies": [
        "EliteMasterEric-SlimeTamingFix-1.0.2",
        "itsmeowdev-DoorFix-1.0.0",
        "kuba6000-LC_Masked_Fix-0.0.1",
        "linkoid-DissonanceLagFix-1.0.0",
        "Splitface-LCSprayFix-1.0.3"
    ],
    "require": {
        "EliteMasterEric/SlimeTamingFix": "^1.0",
        "itsmeowdev/DoorFix": "^1.0",
        "kuba6000/LC_Masked_Fix": "^0.0.1",
        "linkoid/DissonanceLagFix": "^1.0",
        "Splitface/LCSprayFix": "^1.0"
    }
}

Mod managers supporting the new manifest could actually ignore the dependencies and fully rely on this require format, then when all mod managers support the new notation modpacks could start ommitting the dependencies property.

I'm probably biased in my opinions on this since they're mostly driven by the fact that I've used package managers using these constraints and notations. I also understand that in my history I really required strict constraints but can see that with a larger non programming community these strict constraints could cause confusion. Therefor I'm very curious about the opinions of this community on this proposal.