Semantic Versioning – What Does Backwards Compatible Mean If There Are Breaking Changes?

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.

Assuming that the semantic versioning is used properly, does this indicate that the system is poorly designed since it makes major breaking changes almost every four months?

Not necessarily.

You mentioned in the comments that this is an internal API. Breaking an API is bad, because you break everybody's code. But for an internal API "everybody" is just "you", and you are perfectly capable of coordinating such API changes with yourself, so the pain that is usually associated with API changes is much less worse.

Also, the average could be massively misleading: maybe they had 11 breaking API changes during the first couple of days of early development and have been stable for 4 years ever since? SemVer does allow you to make breaking changes without increasing the major number if the major number is 0, but it doesn't force you to. Maybe they started using SemVer from day 0, even during the prototyping / exploratory phases?