build workflow should produce a unique version number based on timestamp or commit

[JonnyOThan]

Right now, when using build.yml as a CI action all of the artifacts end up with the same version number (whatever is committed in the repo). We should set the 4th segment of the version (usually named "build", conveniently) to something unique (timestamp, commit, etc) so that people consuming the artifacts can accurately report what version they were using.

[drewcassidy]

https://github.com/drewcassidy/KSP-Conformal-Decals/blob/main/Scripts/version.py#L15-L23 my solution was to use the commit hash, then a large number for releases

[Twinki14]

I'd suggest two totally seperate versions,

• Production, semantic based (1.0.0)
• Development, semantic based with a short commit hash suffix (1.0.1-dev-2135acc or 1.0.1-dev / 1.0.1-beta when produced from a GitHub release)

Production built from a GitHub release that isn't marked as pre-release

Development built any time a GitHub release is made marked as pre-release, or on any push to the default branch

[drewcassidy]

MinVer has a nice solution for this using the git commit distance and hash

results in an InformationalVersion like so:
0.3.1-alpha.0.44+72e85fe6aa59466bb50da1f43d49e38a40ac0c6d
meaning a commit after the 0.3.0 tag by 44 commits. This value gets printed to the KSP log under "Mod DLLs found:"

Supporting this requires no changes in KSPBuildTools