We use Git and Jenkins as our build&release system and each build is assigned a version number which looks like this: 6.0.12345. Here, the 12345 part is a counter which increments with each build. The counter is stored on the build server in a simple text file, which is rewritten every time a build occurs. It’s worth noticing that this file is not under version control.
I was thinking about more elegant way to manage build numbers, which will allow for easier portability (say move build server to a new machine) and scalability (adding another build server would be very tricky with the current setup).
The only thing I can think of now is using commit hash instead of number, but this will make it difficult to say which of two builds came first, also, I don’t think customers will be willing to accept such a change.
Any ideas are appreciated.
When you say that each build is “assigned a version number”, do you mean that the commit associated with that build is also tagged with that build number in git? If you aren’t doing that, you should:
git tag -a 6.0.12345 -m "Successful build on 2016-01-04 23:09:01.441"
git push --tags
If you are, then you could just use git to tell you what the latest tag is instead of tracking it separately:
git describe --tags $(git rev-list --tags --max-count=1)
Your build system would then parse that tag to get the last build number, increment it, and create the new version tag.
3