> You're basically suggesting reimplementing semver in a clunkier way. There is a huge difference: Most languages and runtimes do not support having the same d

> You're basically suggesting reimplementing semver in a clunkier way. There is a huge difference: Most languages and runtimes do not support having the same dynamic library twice in the same process. This means that if you just bump the major version number, you can only have one version of a library in a process. Now consider the case that your library L1 has a dependency L2 and is included in an application A which also includes another library L3 which has the same dependency L2 as you. Now think what happens if L2 has a breaking change, and you upgrade L1 to use the new version, but L3 does not work with the new version, and does not upgrade it. In this case, the application A - the user of your library - is broken, and there is little the developer of A can do about it. However, there are two kinds of libraries: One which access global objects, like GUI libraries, the glibc socket library, and such. Or which provide data interchange formats, such as Python's Numpy. These regularly need to be unique across an implementation. And the other ones which do things like data transformation, parsing configuration, some numeric processing, and such. In this case, you could link L2 statically, if you were using C. r you could L2v2 and the library l3 could use L2v1. But in most languages and runtimes, this will only work if L2 version 1 and the incompatible L2 version 2 have a different name. > Just bump the major version but continue supporting the old major version with security releases etc. My experience is that the "continue supporting the old major version with security releases etc" almost never happens. People release incompatible versions and force upgrades on users because they do not want to do extra work. If they were supporting older versions, they would still have to do some of the extra work. They might do it some time in some cases but even then they will cease to do it soon. If one wants continuous updates and support, one is usually MUCH better off to use libraries which just do not do compatibility-breaking changes. Because these have decided to do the work required up-front, and have little extra work with supplying urgent fixes to an old API interface.