Summary
Semantic Versioning (SemVer) claims that as long MAJOR doesn’t change (aka a major bump), nothing will break. In practice, the methodology is applied poorly, leaves its promises unfulfilled, and comes with a long tail of unintended consequences.
Python and Go packages are more likely to suffer from breakage caused by unintentional side-effects. You can’t rely on the semantic meaning of SemVer and you must treat every update as potentially breaking. Postponing problems is generally a horrible idea because most problems only get worse the longer you neglect them.
SemVer promises freedom, but in reality it delivers additional pressure and work. Maintainers can do whatever they want, as long as the major version is zero. That leads to many maintainers sticking to their beloved zero forever. Most open source projects don't have the capacity to maintain multiple major branches.
If you maintain a public package and pin the major version of a dependency of yours, you transitively do this to the applications of your users. In the case of security-sensitive projects – like cryptography but also web frameworks and their dependencies – this has potentially catastrophic consequences. Don’t ever pin major versions, unless you know they’re broken.
