Retroactive mod compatibility #3910
Comments
|
Here's where this problem shows up btw, as ckan grabs v1.12.19.0 instead of the last legacy version of v1.13.2.2, specifically because v1.12.19.0 is the last version that doesn't specify RO's max version as 15.99. 1.12.19: (listed as 1.12.9.0 for some reason) Picture of problem: |
|
I've updated the issue to clarify that the extant setup was a max_version for depends (or recs), and a min_version for conflicts. |
This is the crux of it, compatibility breaks are rough all around. In a typical scenario, the depending mod would release a new update that works with the new version of the dependency mod, everyone would upgrade both mods, and everything would be fine, even though technically a broken configuration is possible if the user goes out of his or her way to select it. That couldn't happen in this case because Back when the game used to break compatibility, the least bad solution was via versioning: You could declare support up to game version 1.10 in your version file when that was the latest, and when 1.11 was released, you'd test your mod and, if it still worked, update the remote version file to indicate compatibility with 1.11. If you did this with each release, then the older releases would all have a max compatibility less than 1.11, so there would be no risk of installing them accidentally. Applying that strategy to mod dependencies would require knowing in advance which mods might break compatibility, and keeping those dependencies versioned all along, which would be a lot more maintenance. Probably the cleanest option would have been to make the newer versions of RealismOverhaul, ROCapsules, ROEngines, and ROSolar conflict with RP-0. That would have put the knowledge of the incompatibility in the modules that broke it, and would only have required updating the latest versions, rather than going back to the start of RP-0. |
I think (though I don't recall) we released one more 1.x RP-1 update after RP-1 2.x released. Certainly I set up the CI and the netkans so they would handle releases on both branches. So version hold wouldn't work in this case. As for an upgrade path, as you say the gameplay was different enough that we wanted to offer users the option to play either for a while, including via new installs (principally so they could keep playing old saves in new installs, I think we had a nag about not starting fresh saves in RP-1 1.x. Goodness knows there couldn't be a an upgrade path for saves between the two versions, it'd be like an upgrade path between Proc Fairings and SAF). I'd be surprised if this was the only instance of such a thing in KSP's history, where there's an update with significant enough change in gameplay (or features or whatever) that--whether supported by the devs or purely from players--some older version is deemed the 'legacy' version. Yes, the "ship with a max supported version of each mod and then update the netkan when compatibility is tested" is a partial solution, but then it runs into the above problem in reverse: you'd still have the "all the old .ckan files" issue, wherein you'd have to port the same max_version changes back to all relevant .ckans whenever you bump it for the current active release. Otherwise you'd be locking users to unsupported/broken/lacking-features/whatever versions of your deps/recs. Yes, the clean solution is probably what we should have done (although insufficient--RP-1 would have have needed the min_version for them all)--though it was really only workable because we controlled all metadata and all mods were being updated actively. In the original scenario, involving different authors, it's less simple. |
|
Related to this issue: #3849 |
|
Having re-read this a couple of times, I think KSP-CKAN/CKAN-meta#3206 was the correct solution. If compatibility breaks are done in ways that require updating old versions (rather than adding conflicts to the latest version of the breaking mod as suggested above), then we already have a way to do that: a pull request in the CKAN-meta repo. Closing this as completed. If I've misunderstood something or if there is a specific bug identified here or a feature to request, please let me know. |
This was very time-consuming to do though (>1 hour), surely there should be a better way to do this. It certainly is a solution, though perhaps there could be some sort of system for modders to list certain versions of mods as compatible/incompatible for all versions of their mod and then a bot would do it automatically. |
|
Yes, there is a better way to do it, as mentioned above:
That solution would have required zero hours of going back through CKAN-meta to edit. |
(Please move me to NetKAN or whatever repo is more appropriate, if another repo is better.)
Writing this issue out here rather than losing it in discord. We've recently come across an interesting compatibility wrinkle, and I'm honestly not sure if the best answer here isn't "just live with it", but it is a problem for users and for mod authors so I wanted to write it out.
Consider two mods, mod A and mod B. Both have been around for a while, and mod A depends on mod B. Let's claim the current versions are mod A 1.19 and mod B 1.54.
Now imagine the author of mod B releases a compat-breaking update, mod B 2.0. The author of mod A very sensibly says, ok, let me modify my netkan so mod A requires max_version 1.99 of mod B (and conflicts with min_version 2.0 of mod B). And this change is applied to mod A 1.19 when the netkan is next inflated. However, when a user with mod B 2.0 installed tries to go and install mod A, they find they can--they're served mod A 1.18. This is because while the versioning changes were applied to the current .ckan of mod A (which was reinflated from the netkan), it was not applied to previous .ckan files.
Now, obviously we don't want it to be the case that any netkan change is retroactively applied to all .ckan files, because that would lead to older versions of mods that are flagged for, say, max KSP 1.2, to be served for 1.12 if the netkan is updated right along. But it's also true that we don't want this situation to occur, and it's also not desirable for it to be standard practice to set max_version for dependencies/recs/whatever. In most cases, you do want the latest version of the other mod, and you can't know ahead of time what's going to be compat-breaking.
For a concrete example, this situation was discovered by this pair of pull requests: KSP-RO/RP-1-ExpressInstall#2
When RP-1 v2.0 released, I changed the RP 1.x netkan to have a max version requirement of <16 for Realism Overhaul, and <2.0 for the ROMods (ROTanks, ROEngines, etc), and a conflicts with >=16 and >=2 respectively. This was because the 16.x+ RO and 2.x+ ROMods were compat-breaking and designed for RO 2.0+
This worked fine due to the ordering in the express install (although if one were to install manually, I'm pretty sure the situation outlined above would occur). However, when the PRs were merged, that resulted in RO v16+ and ROMods v2+ being selected before figuring out what versions of RP-1 (rp-1.netkan and rp-0.netkan) to offer. This resulted in the version of RP-1 v1.x (rp-0.netkan) being offered being an older version that didn't yet have the max_version requirement and, crucially, did not describe itself as legacy RP-1, confusing folks. (If they selected it they also would have had broken installs due to having v16+/v2+ companion mods.
My present workaround will be simply to remove support for legacy RP-1 installs via the express install (it's been long enough since RP-1 v2.x shipped), but it does raise this issue, which I wanted to bring to everyone's attention.
The text was updated successfully, but these errors were encountered: