support auto git semver versioning of packages

[reubenmiller]

Signed-off-by: Reuben Miller reuben.miller@softwareag.com

Proposed changes

Support an automatic versioning based on git describe. It provides a way to generate binaries/packages with a unique version number between official releases (e.g. as soon as it is merged into main).

Versioning overview

• Version is determined from the distance from the last git tag

  • if commit is tagged, then the version will be the tag (eg. 0.9.0). For official releases the Cargo.toml should still be updated, but the file should be updated and committed, then tagged!
  • if commit is 2 commits passed the last tag, then the version will be 0.9.0-2-gabcdef10, where it follows the schema <tag>-<distance>-g<commit_sha>

• support setting a custom version (for dev and testing purposes only)

  export GIT_SEMVER=0.9.0-experiment-0.1
  ./ci/build_scripts/build.sh

The relationship between the version, the git tag, and the distance from the last tag is illustrated in the following table.

Last tag	Distance from tag	Version
0.1.0	0	0.1.0
0.1.0	1	0.1.0-1-gabcdef10
0.1.0	2	0.1.0-2-g091dae88
0.2.0	0	0.2.0

Example

Below shows two official releasese 0.1.0 and 0.2.0. As soon as the feature-x branched is merged into main, the automatic git version will be 0.1.0-1-gabcdef12

gitGraph
       commit
       commit id: "release(0.1.0)" tag: "0.1.0"
       branch feature-x
       checkout feature-x
       commit
       checkout main
       merge feature-x
       commit id: "0.1.0-1-gabcdef12"
       commit id: "release(0.2.0)" tag: "0.2.0"

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[reubenmiller]

Sorry I had to fix some of the formatting in the PR description. It should be finished now

[didier-wenzek]

Approved. It works like a charm!

[PradeepKiruvale]

code changes LGTM. Since all the build.rs code looks the same, Why don't we move it to some crate like build and then reuse it?

[reubenmiller]

code changes LGTM. Since all the build.rs code looks the same, Why don't we move it to some crate like build and then reuse it?

Yeah that is a good point. I'll add it to the list of clean up stuff and hopefully create another PR soon.