Improve in-game display of module versions - release/snapshot, git hash

[Cervator]

Summary

The game reads module version info out of module.txt to display on the Advanced Game Setup screen listings like Core:3.0.1 or Cities-1.0.0-SNAPSHOT

We don't bump module versions often enough to have a high degree of confidence that what the game is showing actually matches a specific version of module code.

Gradle uses metadata the game could perhaps also utilize, in two primary ways

• SNAPSHOT or not - indicates whether a module build is a "dev" build or a stable release
  • This has become unreliable after More Gradle: now with makeshift release management! Ready for v3.0.0 #3871
• Consider attaching the Git hash in place of -SNAPSHOT to indicate dev builds

Detailed background

After #3871 Gradle now is better at deducing versioning for a module based on the environment. module.txt can just contain "version" : "3.0.1" and Gradle finds out if it is a snapshot or a release - details in that PR.

This helps Jenkins determine whether it should publish a release, a snapshot, or nothing at all.

The game zip still just gets whatever we stick into the built module jar file, which includes an unmodified module.txt and remains blissfully unaware of what Gradle thinks.

Doing this avoids having to toggle on and off the -SNAPSHOT in code, and is one step closer to not necessarily managing version in code at all (Git tags etc). But there are two drawbacks:

• After More Gradle: now with makeshift release management! Ready for v3.0.0 #3871 Gradle expects to manage the snapshot state based on environment cues. The game doesn't have this so it will happily show a snapshot as a release
• In both cases (new current state and an ideal Git metadata state) the game doesn't know about Gradle or Git. In some cases that can be read, in others it should be provided via a version file

We need to make the game smarter: Either we update the module.txt on the fly during jar builds (which still doesn't help when running from source) or we deduce extended version info based on the environment.

Scenarios

Built jar from Jenkins

In this case we could simply update Gradle to modify the module.txt being copied into the jar. We have access to the Git hash of the branch being built.

• If a release then that is only expected to be built once. Simply leave the standard version in place by itself, so for example Core:3.0.1
• If a dev build then we're doing snapshots, but it can be hard to know which snapshot we're dealing with. Append the Git hash instead of -SNAPSHOT so Core:3.0.1+abc123 ("build metadata" as per the SemVer specification follows a +)
  • Possibly we might still need the snapshot in the version for Artifactory to work. In that case we could just code the UI to exclude that for display as we don't really need to tell a user in two different ways that something is a snapshot (both with the word + the hash)

Running from source

In this case I'm not sure. We can't rely on automatic modifications to module.txt (probably?) so we should probably load context from the environment. Maybe modules present in source are automatically marked with their Git hash, while jars load from module.txt like from Jenkins

Game reading new metadata

While updating `module.txt is easy enough reading it might be trickier, if gestalt-module expects a given format. Both for display and module resolution. Especially if we need to make it context sensitive somehow. More a word of caution for possible research.