Virtual ksp_version_max

[dbent]

From the discussion in #1156. I propose the addition of "virtual" ksp_version_max functionality to CKAN clients. This means that an old version of a mod cannot be more compatible than newer versions of the same mod.

For example, if AwesomeMod-1.0.0 specifies:

{
  "spec_version": 1,
  "identifier": "AwesomeMod",
  "version": "1.0.0",
  "ksp_version": "1.0"
}

And then AwesomeMod-1.1.0 is released which specifies:

{
  "spec_version": 1,
  "identifier": "AwesomeMod",
  "version": "1.1.0",
  "ksp_version": "1.0.3"
}

Then AwesomeMod-1.0.0 gains a virtual ksp_version_max of 1.0.3. If we introduce exclusive comparisons as described in #1160 and #1173 then it becomes <1.0.3.

This resolves the issue that when KSP 1.0.4, 1.0.5, etc. are released clients are offered old mods as "compatible", when newer versions are available. This would resolve a lot of KSP-CKAN/CKAN-meta#623.

[pjf]

1. I agree with this entirely, but...
2. I think we should do this in metadata.

I would love to see the CKAN metadata be useful for more than just our own clients. KMA² is starting to use it, and there's at least one website that's working on a more human-friendly website display.

Of course, humans shouldn't be making these checks in the data; instead we can have bots detect and correct these sorts of errors, probably as an additional stage after the netkan indexer runs. This wouldn't require a spec change if we're writing actual preceise/max versions into the files, which I think we should be doing.

The advantage here is that:

1. Both existing and new clients have higher quality metadata; we're fixing obvious servers server-side, rather than client side.
2. The complexity is reduced. A human can look directly at the metadata and say exactly what KSP versions will work with that mod. If the adjustments are done in the client, then one needs to understand what other versions of a mod exists to understand what compatibility levels a specific mod will reveal.

[dbent]

I think we should do this in metadata.

Fine with me, my one worry is that this would be the first time that KSP version information would not be ultimately derived from explicit human choice. So we'd be putting an implicit calculation permanently in the metadata, with no way to (easily) determine after the fact if it were human created or not.

I'm worried this might cause some problems down the line, especially if newer versions change their compatibility after we've written the "virtual" version. Although I can't think of any such problems at the moment, so... :+1:.

[solarsootysmudge]

Ref #1798 . Topic back in discussion