My hot take is that SemVer can only really work if the team also restricts how much of the existing code they are willing to change. In particular, the point i

My hot take is that SemVer can only really work if the team also restricts how much of the existing code they are willing to change. In particular, the point is stability of existing code, which means that you basically have to somewhat restrict yourself to use the existing ways as much as you can. Any codebase where folks are building new ways of doing things will build up odd mismatches in what is actually supported versus what exists, and then gives incentives for folks to remove old ways. Worse, SemVer is useless from small teams where they are not budgeting time and effort to maintain all of the old version bumps. Pointedly, just updating the feature version can help folks know it is dangerous to upgrade. But, if you aren't going to maintain the old versions forever, it is equally dangerous to not upgrade.