Consume and use mod/ksp version metadata in .versions files

[cgruber]

Nearly all of my mods have "KSP Version: unknown" yet nearly all of them publish .version files with min/max ksp versions as well as other useful metadata. TinkerTime could make use of this explicit metadata from developers.

So far I see two forms of .version files - a short and long form, related to format of version numbers - beyond that, the metadata seems plentiful with a variety of optional information TinkerTime could harness, and includes NAME, URL (of the version file), CHANGE_LOG_URL, DOWNLOAD (url), a GITHUB metadata section, as well as VERSION, KSP_VERSION and often KSP_VERSION_MIN and KSP_VERSION_MAX

An example of the short version is RemoteTech:

{
    "NAME": "RemoteTech",
    "URL": "https://raw.githubusercontent.com/RemoteTechnologiesGroup/RemoteTech/master/GameData/RemoteTech/RemoteTech.version",
    "CHANGE_LOG_URL": "https://raw.githubusercontent.com/RemoteTechnologiesGroup/RemoteTech/master/CHANGES.md", 
    "GITHUB":
    {
        "_comment": "GitHub support requires build tags that include a #.#.# string",
        "USERNAME": "RemoteTechnologiesGroup",
        "REPOSITORY": "RemoteTech",
        "ALLOW_PRE_RELEASE": false
    },
    "VERSION": "1.5.1",
    "KSP_VERSION": "0.25.0",
    "KSP_VERSION_MIN": "0.25.0",
    "KSP_VERSION_MAX": "0.25.4"
}

This has a simple MAJ.MIN.PATCH version string for each. A deeper JSON structure is provided in others, like community resource pack which has:

{
     ...
     "VERSION":{
         "MAJOR":0,
         "MINOR":3,
         "PATCH":1,
         "BUILD":0
     },
     "KSP_VERSION":{
         "MAJOR":0,
         "MINOR":90,
         "PATCH":0
     },
     "KSP_VERSION_MIN":{
         "MAJOR":0,
         "MINOR":24,
         "PATCH":2
     },
     "KSP_VERSION_MAX":{
         "MAJOR":0,
         "MINOR":90,
         "PATCH":0
     }
 } 

Looking at KSP-AVC the json isn't specified outside of the code, but you can see the effective-spec by inspecting the code here: https://github.com/CYBUTEK/KSPAddonVersionChecker/blob/master/AVCToolkit/VersionInfo.cs. Creating a GSON (or other) based java parser for these files should be a reasonable effort and can make TinkerTime hooked in to a growing community standard (and off-load some of the stickier heuristics to gather this metadata from scraped web information). Given that for open-source/github-based projects, these version files are present and searchable, one could even use it to create lists of known plugins to select-from.

[cgruber]

For the record, I'm willing to put my money where my mouth is, w.r.t. actual pull requests - but probably not until the holidays.

[oharaandrew314]

I didn't know this existed. I'll look into adding support for it. On 16 Dec 2014 14:48, "Christian Edward Gruber" notifications@github.com wrote:

For the record, I'm willing to put my money where my mouth is, w.r.t. actual pull requests - but probably not until the holidays.

— Reply to this email directly or view it on GitHub https://github.com/oharaandrew314/TinkerTime/issues/153#issuecomment-67219793 .

[oharaandrew314]

Hey @cgruber, Google has me set up for a technical phone interview in January with coding in a Google Doc. Do you have any advice for it?

[oharaandrew314]

Note to self: investigate .version file and come up with a new ticket stating data to be extracted from the file, and how it will integrate with Tinker Time.

[cgruber]

Re: google interviews - feel free to contact me off-thread and we can talk about it. same username at google. Happy to give general advice.

On Tue Dec 16 2014 at 5:03:45 PM oharaandrew314 notifications@github.com wrote:

Note to self: investigate .version file and come up with a new ticket stating data to be extracted from the file, and how it will integrate with Tinker Time.

— Reply to this email directly or view it on GitHub https://github.com/oharaandrew314/TinkerTime/issues/153#issuecomment-67240853 .

[oharaandrew314]

Obsolete by #228