Setup Versioning and tag

[JeanPhilippeKernel]

To avoid using many tools and keep the process as easy as possible, we want to go to with the Pure Git Semver way.
Doing that means, we'd structure our git commit messages with:

• Breaking changes --> major update
• feat --> minor update
• fix --> patch update

On develop branch the version should look like x.y.z-dev
On master, the version should look like x.y.z

The process might involve writing a bit more PowerShell script, and for now we want to cover the dev branch.

For now, the following libs/apps should be cover and the task will be marked completed once there are done:

• zEngineLib
• tetragrama
• obelisk

[JeanPhilippeKernel]

@MathewBensonCode since you're authoring the build system i'm seeing this as a task under your scope, but it's a kind big chunk tho :)
but lemme if you don't have bandwidth for it

[MathewBensonCode]

I think this should be straight forward if we use Git Tags instead of the commit messages.

Then We can also use the CMake project Command to set the project number and create a commit when this changes. The ground work should be in place as the different libraries have their own project call.

What isn't clear is where the versioning is to start, you can create tags for some commits in the past and enumerate them according to points of interest then we continue from there, or we could just start now with everything at version 0.0.1

I'll try and draft something up and send a PR.

[JeanPhilippeKernel]

Yes, we want to combine Git Tag + script to automate the whole process.
The commit message is a way for the script to rely on and bump the right number so we wont have to do it manually
I think we already have a tag v0.2.0 I've created years ago (just for test ) , maybe we want to start from there.

Here is the idea :

A script that bumps the version based on branch and the commit messages
we can use the script inside CMake with execute_process to drive the Project Command VERSION
something like:

execute_process(COMMAND generate-version.ps1 OUTPUT_VARIABLE ZVERSION)

project(... VERSION ${ZVERSION} LANGUAGES C)

...

• On development branch (mostly on develop branch and/or sub-branches)
  the script just output the VERSION in the console, no need to push it
  I think the script can relies on command git describe --tags --always to get latest version,
  Should look like v0.2.0-4-g7a2b3c (Tag + number of commits + short hash) and if we can customize it to add -dev on it, that would nice , but okay if we can't

• On release branch
  The script calculates the new actual version with : git describe --tags --abbrev=0
  and bumps it based on commit messages fix, feat:, BREAKING CHANGE etc

on Github release process we can reuse the script and configure the pipeline to generate a release note as well

[MathewBensonCode]

I believe that this script shouldn't be part of the visible source code, but should be embedded privately in the main repository. So it should be something like a git hook that runs when merging pull requests and ensures that the main repo has the tags based on the logic. There is likely something like this available in the github market places, something like https://github.com/marketplace/actions/github-tag