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

KSPModdingLibs / KSPBuildTools

MIT License

2 stars 4 forks source link

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

Open JonnyOThan opened 1 month ago

JonnyOThan commented 1 month ago

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 commented 1 month ago

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 commented 2 weeks ago

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 commented 1 week ago

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