In practical use of semantic versioning my biggest problem isn't with the concept itself, but with my (personal) human perception of version numbers as seen thr

In practical use of semantic versioning my biggest problem isn't with the concept itself, but with my (personal) human perception of version numbers as seen throughout other software and projects on a day to day basis. A major version bump usually indicates a lot of changes, new features and most of the time also breaking changes. The major versions kind of indicate important milestones and not only "if you update, some stuff is incompatible"! So when I have to make a small, but useful or necessary, breaking change I'm reluctant to either bump the major version or deploy the change at all until there is enough reason to bump the major. I don't want to have a small, early stage library, to be on major version 6 just because I made multiple small edge-case changes in the API responses. While actually not true and maybe not even seen like it by most developers, I would see a version 6 as a rather mature project. It's a small but often occurring pain factor with semantic versioning for me and the easy way out is to just make a minor version bump on these small breaking changes. On the other hand, I know that it's useful to be reluctant with breaking changes, especially on widely used and big projects, because it takes other people more effort to upgrade the version. But for my small projects I would personally prefer a fourth number: major.breaking.minor.patch. The breaking part is used for simple API changes, especially for different edge-case behavior, while major is reserved for big milestone upgrades.