Build number when supporting previous version

Question

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.

Answer 1

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