Max KSP Version isn't using the most recent mod version

[mheguy]

Easily seen with RealPlume which requires a forced epoch. Its most recent version is 1-v0.4.1 but we catch v10.0.0 for the sake of Max KSP Version

[Postremus]

It uses correctly 1-v0.4.1 of RealPlume for me.

[mheguy]

Ack you're right the bug doesn't exist as I described it. I was forcing an epoch to the mod and got ahead of myself. 1-v0.4.1 didn't exist at the time I reported the bug, v0.4.1 was the max version at that time, and the GUI displayed v10.0.0

I created https://github.com/KSP-CKAN/CKAN-meta/tree/kspmaxverbug which reverts the creation of the forced epoch 1-v0.4.1. If you replace the default repo with that you'll see the bug as it was when I reported it.

http://puu.sh/j7kYP/ca53b12c21.png

[mgsdk]

Another case is InfernalRobotics. Latest version states 1.0.4 compability in the metadata, but the shown result is from an earlier release stating 1.0.2.

Near Future Solar has the same issue.

[Postremus]

NFS has for ksp 1.0.4 the version 0.5.3. One release however has the version 0.5.21. The "max compatible" column uses registry.latest() to get the newest release for any ksp version. This returns 0.5.21.

[pjf]

I'm not sure this is a bug in the GUI per se, rather an artefact stemming from the fact that mod version numbers don't always follow our version comparison rules, with 0.5.21 being a perfect example.

We should be able to happily epoch-bump these mods to solve the issues. If we hide the epoch in the display (which I think would provide a nicer user experience) then the users won't even notice. :)

[politas]

Epoch-bumping is not the best solution. We should populate the "Max KSP" column data from the same version we get the "Latest" version for the mod from. Grabbing the list of .ckan files on Github in alphabetical order is absurd, and we'll be constantly bumping epoch numbers every time a mod author adds a layer to their version numbering. Epoch bumping is the wrong way to fix this. The GUI should handle it better. I see 26 mods currently experiencing this issue (and that misses the many that happen to have a compatible version in the version that's being picked up incorrectly), and it's going to keep happening.

[politas]

Ok, I've gone through all the instances I could find of mods listing as compatible with 1.0.5 but showing Max_KSP as a lower version and done something to all of them. Not sure if all the workarounds will be successful, but I think most of them will at least.

[politas]

Should point out that the abstract column is also populated in the same way, using the "latest release" without paying attention to compatibility. I'm guessing author is, too, but I haven't seen a clear example of that.