Search code examples
gitcontinuous-integration

How to avoid keeping version number in source code?


Up to now we keep the version number of our source code in a source file. This version gets increased after every successful CI run.

(The version number looks like this: YEAR.MONTH.X. So it is more a build number. More is not needed in this context.)

This means the version of central libraries get increased several times per day. Since the version number is stored in a file in the Git repo, every increase of the version number is a new commit. This means roughly 50% of all commits are not made by humans, but by CI.

I have got the feeling, that we are on the wrong track. Maybe it is no good solution to keep the version number in CI.

How could we avoid the "useless" CI commits which just increase the version number?

How to avoid keeping version number in source code?


Solution

  • Premises:

    I assume these are the premises under which the solution is discussed.

    1. Currently version number is kept in a git-tracked source file, but you are OK to get rid of it.
    2. No one manually manages version number, nor triggers a release procedure, which includes: (a) increase version number, (b) build from source and (c) store the built result somewhere. These are taken cared by CI, and SHOULD remain that way.

    Solution:

    1. Instead of writing to a source file and create new commit, CI simply tag the specific commit that passed CI check, then push the tag to remote repo.
    2. The build script should read the tag of current HEAD commit, and use it as the version number for publishing a release.
    3. Optionally, you might want to use git filter-branch to rewrite your existing git repo history, tag previous release commits for consistency, remove and stop tracking the version number source cile, then get rid of those CI commits.