3

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 ?

Improve this question
1
  • I guess the better approach is not to avoid these commits, but to find a way of filtering them out when viewing the history. +1 either, it may be a bad idea, but nevertheless a good question.
    – Doc Brown
    Commented Feb 1, 2021 at 11:56

3 Answers 3

Reset to default
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).

Improve this answer
1

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.

Improve this answer
2
  • I already use tags (and tag the commit on which I change the version number before compiling my app). The issue I have is because the version number is in a tracked file (either code or config file) I have no other choicce yet than commiting when updating that number.
    – f222
    Commented Feb 2, 2021 at 8:20
  • @f222 Instead of getting the version from a file, you could fetch the version directly from git tag during build (it could be saved into a temporary file for convenience but the file itself would not be under source control so you would not need additional commits to change it).
    – Michał Kosmulski
    Commented Feb 2, 2021 at 8:39
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.