Terraforming-mars: Add SEMVER tags on changes

[pocc]

Proposing to start at 0.0.0 with a new PR

Given version X.Y.Z,

X => Major version. This is some form of release. This issue contains no proposal for what constitutes v1 at this time.
Y => Minor version: New feature added that is user visible.
Z => Patches/Bugs: Trivial additions and bug fixes.

To tag, use -a like git commit -a v0.0.0 -m "commit message", and push with git push origin master --follow-tags. Obviously there are other ways to do this as well.

[chosta]

That would be great if all devs agreed on it + enforced some rules and proper git flow. The thing is that work is going on well in the repo and restrictions / rules might cause more trouble then be helpful. But its a good time to open the discussion about processes and streamlining the work.

[pocc]

So make adding a tag tied to making a commit so no work is required.

possible pre-commit hook options:

• auto-increment patch in tag if on new commit, there is a newer changelog wiki entry
• auto-increment patch in tag on any commits that have "Merge pull request" in the message

At worst, use CALVER or add 7char commit hash to the tag.

What do people think?

[nwai90]

If we adopt this I would go with "Merge pull request" as it's cleaner - a single PR usually comprises of several atomic commits related to the same functionality

[pocc]

Someone with push access needs to run this script to add tags. It should add 696 that are tied to pull requests. Once these tags are added, I have a different shell script (pre-commit) that will automatically add tags to pull requests going forward.

[one liner]
i="0";for c in $(git log --format="%cI %H %s" | grep "Merge pull request" | sort); do git tag -a "0.0.$i" $c; i=$(($i+1)); done

[expanded for readability]

i=0
for c in "$(git log --reverse --format="%H %cI %s" | grep "Merge pull request")"
  do echo "$c" | while IFS=" " read -r hash msg
    do git tag -a "0.0.$i" -m "$msg" "$hash"
    i=$(($i+1))
  done
done

You should be able to verify that it's worked by running git tag | sort -V
and see the tags that have been created.

If you are comfortable with these tags, enter git push origin --follow-tags

[pocc]

Alternatively, set a commit to tag 0.0.0 and the pre-commit script will increment patch with pull requests from there.

[bafolts]

@chosta has a good point that we seem to have a good thing going with what little process exists so I would be weary to get in the way and ruin a good thing.

I could see a version tag being helpful if displayed to the user for when bug reports are filed. Often times now it can be unclear what version of the game was running when a bug report comes in. We aren't taking advantage of it today but as this is a node project we have the 1.0.0 version in the package.json file.

https://github.com/bafolts/terraforming-mars/blob/master/package.json#L3

I would be weary to block development with a pre-commit hook but I have seen tooling that updates the package.json and creates a tag based off commit messages on a CI build server. There should be no problem with running a tool like semantic-release after each successful build after a merge which would increase the version automatically based on commit messages.

https://github.com/semantic-release/semantic-release

That tool would also provide a change log that it keeps up to date as each commit is merged. A tool like this shouldn't get in the way and I think it would achieve the tagging goals.

[pocc]

So stepping back for a second, the problem is that there are multiple servers running this software and it's not clear from the webpage which version they're running. terraforming-mars.herokuapp.com is running "the most recent version" and tfm.msydevops.fr is running "an earlier version". Versioning solves this type of confusion. Taking an even bigger step back, versioning is to help support users (of which there are now many).

Ideally this could be added to 2 places:

1. Start page: at the bottom (this has buy in from @nwai90 and @vincentneko)
2. In game: At the bottom of the preferences popup

Something like v0.1.2-5930b0f (2020-10-01)

https://github.com/semantic-release/semantic-release
That tool would also provide a change log that it keeps up to date as each commit is merged.

Using a CI action seems like the best solution. My pre-commit hooks is a bash script which could be added here. Can you test out the minimal github actions configuration and see whether you like it? It looks like it's based on Angular commit guidelines, which might be hit and miss if people don't use the right keywords.

[bafolts]

CI makes sense and would avoid introducing merge conflicts or giving contributors more work. I will check this out. At a minimum the goal of displaying a version on the UI makes sense. At first we could display the commit hash with last commit date and work from there. That would at least provide the hash and a date which should help date the release.

[bafolts]

A version is being displayed. The heroku instance isn't populating the value. Will need to re-visit.