[giovannibajo1]

> Version history. For projects using SemVer, frequently changing major version numbers is an obvious red flag. Note that many old, stable projects don’t use SemVer.

This matches my experience. Obviously it's impossible to generalize without making mistakes, but I started to notice that projects that loudly talk about their use of SemVer often break compatibility. In other words, it seems like they think SemVer is a way to liberate them in breaking APIs because now they have a way to tell the world about it explicitly, and so nothing can go wrong.

Ecosystems that have adopted SemVer massively do not value backward compatibility (npm comes to mind), and their package managers often have to provide solvers for complex dependencies; users can get to a corner where they must upgrade something but they can't because it depends on something else that bumped the major version and now the interfacing code has to be rewritten.

Go is an ecosystem that values backward compatibility a lot. They are using SemVer as well now but on the other hand they say that modules shouldn't really bump major version that often, if at all (which in turns makes me question whether adopting SemVer has been a good idea, or a compromise that they had to take to concede something to the community subset that was pushing for a more standard package management solution).

I think Qt is a project that uses SemVer (before it was named so!) in the right way. They break major version every 8-10 years, and they struggle a lot to make sure not to do that often. In C++, it's not even easy because of include files and ABI, but they manage to keep the ABI stable across all minor version upgrades, so that you can upgrade a minor of Qt without even recompiling your software using it.