Semantic Versioning – How to Name Different Branches with Identical Functionality

It's never explicitly spelled out, but careful reading of semver.org suggests that a version is associated with a proper release, not a VCS commit. So naturally, if you make one release that has multiple bug fixes, you increment the patch component once. Leaving large gaps to account for intermediate states that don't have a version (not even in principle, like broken releases that have been withdrawn) makes no sense.

You could of course make a release for every single tiny change, but this is probably not desirable: It's a lot of work for you, it wastes user's time and bandwidth with frequent updates, and it results in ludicrous version numbers and release logs. There are various policies for when to release, and which works best is mostly a matter of opinion and the quirks of the project and its user base. Some common options are:

• Some project release once every X time units, regardless of how many or few changes were done.
• Some projects release once a subjective threshold of "enough changes" is reached.
• Some projects have milestones: "We'll release vX.Y once we have this thing and that thing done".
• A mix of the above.

Most projects, even when they normally adhere to one of the above, can release out-of-line hot fixes when a particular nasty bug was released in the wild.

Conversely, if you put out new releases so rarely (or never) that most people just track git master, then you fail at semver because these people don't get any backwards compatibility guarantees. The fix is not to give each commit its own version number but to release in more sensible intervals.

You need to better understand the specific requirements you have from versioning.

Most of my cases are end user applications. In this scenario a single version number is sufficient, all I require from the version is to match it to a commit ID.

Other, less frequent, cases are libraries. In this case there is an additional requirement to match to an API version. v123.2 and v124.1 refers to API versions 124 and 123, while 1 and 2 refers to a sequential patch number (it might refer to some bug corrected in both API versions).

This a summary of my requirements. You need to understand yours and be aware to not fall to a situation where mantaining version numbers hinders development, that is not the point. Latelly I've been using a build process to inject the actual commit id, but not sure if I like it that much.