I am developing and maintaining a web-based application that's used internally at my job. I am the only developer and so I'm not really using branches; everything happens on the trunk. I do tag releases in Git with the date and time, and I'm starting to transition to using a build number instead of date/time.
In the production instance of the app (which is just a tag on the trunk), a bug has been discovered that needs to be fixed ASAP. In the meantime, I've been developing new features, but they're not ready to be distributed.
Fixing the bug is easy: check out the tag into a new branch, fix, publish. However, in such a situation, what should the fix's build number be?
If I follow the existing build strategy of incrementing a serial number, my build numbers will be, e.g.
1234: production 1235: development (with new features) 1236: production fix (doesn't have new features)
which doesn't seem to make sense. Alternately, incrementing the production tag's build number would lead to, e.g.
1234: production 1235: development (new features) 1235: production fix
which defeats the purpose of build numbers (uniquely identify a particular build).
Using Git's revision ID is another option, but they're not exactly readable.