Avoid “Updated version number” commits

Question

I have softwares whose version number are stored either in a versionned commit file or in the code (main header file for example)

Because of that before every release we have to update the version number and make a dedicated commit having a message like "Updated version number to xx.yy.zz".

I find that these commits tends to clutter the git tree.

Are there any ways to avoid these kind of commits ?

Answer 1

There is a simple way, if you really want to do this: have the build system read the version number from a file that is not tracked by the version system (it is ignored).

If you want to support third parties to clone and build the repository (e.g. it is an open source project), consider that in your decision. The ignored version number would not be in their clone, and the build system would have to deal with that. Which might be ok, as the build being unofficial, but you got to decide how to handle that.

---

Other things you may do are:

• Have the last number of the version be determined by the build system. For example, autoincrementing or based on the date. So that you don't have to change the version number as often.
• Have the build system read the name of current branch, or look for a tag, in the version control system, and base the version number on that.

You could also have the build system fallback to a commit number/hash. Which would do for not release builds.

If you want to support people being able to copy the source and build it without cloning the the repository, consider that into your decision. For instance, your build system may would not be able to read the version from a branch, tag, or commit hash (and changing version control system is a thing that happens, although, I guess it all ends in git).

Answer 2

One alternative is to use git tags to store versions, as axion release plugin does. This way your version is stored together with the source code but is not part of source code itself and changing it means creating a new tag rather than a new commit.

Answer 3

I would probably enforce this by failing the CI pipeline if the version number has already been released, making it just one of the linting steps. Once you do that you can easily do the same linting in a pre-commit step. Depending on your versioning scheme you can for example say that the version needs to be different from the one on the main/deploy/release branch.