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.


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

  • 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? 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 :/ Jan 10 '14 at 23:16
  • 1
    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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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