Version Bumping – Is Fast Major Version Bumping a Sign of Poor Design?

You hesitate because you don't want to make semantic versioning, you want to make "advertisement supporting versioning". You expect a version number "2.0" to tell the world that you have a bunch of new cool features in your library now, not that you changed the API. That's ok (many software companies and/or developers do that). IMHO you have the following options:

• stick to semantic versioning and live with the fact that you have to change the version number to 2.0.0
• change your versioning scheme to 4 numbers. "1.1.7.3" is your version now, "1.2.0.0" the next one after changing the API, and "2.0.0.0" the first one of the "completely new 2.x product family"
• make your fix backwards compatible (so don't change the functionality of next, just add the valid and current functions). Then you can use "1.8.0" as the next version number. If you think changing the behaviour of next is really important, do it in 2.0.0.

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.