There are roughly two schools of though on build numbers. One is that they must be unique to each release, i.e mirror pretty much a version number, the other one that they must be unique to every commit. I guess you could also make them literally unique to every actual build, i.e each time you compile, which adds even more complexity to insure this stays true across all devs on a given project.

That last one is not easy without some kind of a build server that allocates the numbers itself instead of relying on local builds. Without going that far, I’ve always been a fan of separating version numbers from the build number and often ended up using the commit hash as a build number. It’s unfortunately not sequential but it helps connect any issue/bug to an exact commit in the repo.

The one bonus I often add is a test in the build script for any local changes to the code base. If so, I add a postfix to the build number like -dev or -dirty to indicate that that build does not comform exactly to the commit. That system has the advantage to work across repo branches too, you don’t have to worry about build number collisions when merging.

Sign in to participate in the conversation

A newer server operated by the Mastodon gGmbH non-profit