Semantic Versioning is, at best, a method for the developer of a package to communicate to users of a package the <i>intent</i> of the changes from one release to the next. <i>It does not remove the responsibility from the user of integration testing.</i><p>In the BG (Before GitHub) times, people using a library as part of their application would keep a local "vendor branch" of the library. The vendor branch would go through a complete integration testing with the application before the application was released. When a new version of the library was released, the application developer would review the release notes (CHANGES.TXT) to determine whether the changes were relevant to the application before deciding to update the local vendor branch. If it was determined that the changes were relevant the vendor branch would be updated, a diff would be reviewed (the level of review depends on the application), and then there would be another round of integration testing.<p>In the AG (After GitHub) times, nobody does any vendor branches or third-party code reviews. They just pull the latest version from GitHub without a care in the world. (See the left-pad debacle <<a href="https://www.theregister.com/2016/03/23/npm_left_pad_chaos/" rel="nofollow">https://www.theregister.com/2016/03/23/npm_left_pad_chaos/</a>>) The assumption seems to be that "all code must be kept up to the latest and greatest", which is bullshit. There are many reasons why an application can and should run an older version of a library, each of which must be evaluated by the library user in the context of their use-case.<p>Expecting Semantic Versioning to be perfect solution is both illogical and impossible.