Why build numbers?
Recently one of our test engineers asked if it would be possible to embed an increasing build number on “About” page in our mobile app. The purpose of such build number is to have a single reference point when reporting failed test suites or new problems in issue management tool (eg. Bugzilla).
It is like a dogtag for software: useless for normal users and in daily use — but much needed in case of emergency. And crashing software is an emergency.
At office we are not using any kind of continuous integration server (like Hudson CI) or separate build scripts for small projects. Such servers/scripts are usually configured to create build numbers themselves. For our purpose builds are prepared either by developer or tester in development environment and shared.
Build number requirements
Requirements for build numbers are simple:
Build numbers must be unique.
Using the same source code clone/checkout must give the same build number.Build numbers must reference a single point in project history.
There can’t be two different checkouts giving the same build number.Build numbers must be increasing.
Consecutive and iterative builds must show progress is build numbers. It would be best if they are strictly sequential (N+1) but that’s not a hard requirement.
Usual approach to build numbers includes embedding date/hour and maybe some sequentially generated number. However if you have several builds a day then date-based number is insufficient. It does not identify uniquely a code version that was used to create the target.
Thus you need something more specific.