Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 3 down vote accepted

You could use Semantic Versioning as well as follow the Git workflow. You can move your current development work into a feature branch, bring master back to a commit prior to having done any new feature development and only merge the new features into master when it is ready (i.e. cleared all your tests and cleared QA). That way you can directly apply your bug fix to master.

Following the Git Workflow helps avoid situations similar that in which you are in and would be my recommended approach moving forward

share|improve this answer
So is the build number unique per branch? Or does it just increment remorselessly and context for a build comes more from the version number? – Charles Wood Jan 10 '14 at 23:16
Ah, I guess semantic versioning doesn't use a build number. I just don't like manually incrementing a version number :/ – Charles Wood Jan 10 '14 at 23:16
SemVer does allow for build #s now in development, but the point is to follow it for Release. In the scenario for your question you are releasing a hot fix and need to bump the appropriate #. If you scroll down to point #10 on the server homepage you'll see the note about build metadata – Kevin Jan 11 '14 at 1:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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