This is answered multiple times in the ticket. > The main problem with the current Semantic Versioning doc is that by not mentioning this issue it encourages d

This is answered multiple times in the ticket. > The main problem with the current Semantic Versioning doc is that by not mentioning this issue it encourages developers to break backward compatibility, giving them impression that increased major version number will protect the clients from trouble. > Instead, breaking changes should be discouraged - in majority of cases it is trivial to keep backward compatibility. (For example, instead of altering function behavior, keep the old function as it is and introduce a new function). > If breaking change is still needed, the developer has to make sure the new version of the library can be loaded simultaneously with the old version. In many languages that will require giving the library new identifier, using new namespace / package in the library source code. -------- > In the current form the document is an invitation to break backwards compatibility any time, under a false promise that changing major version number solves all dependency hell issues -------- > Once again, the point of this ticket is to: 1. Remove the false promise that SemVer solves dependency hell by simply increasing major version. 2. Discourage unnecessary compatibility breakages, when it's trivial to maintain compatibility. 3. Several sentences of advice for the cases when comparability breakage is really needed.