Hi Robert.
I would be interested to discuss library versioning.
Lets agree that this discussion is not about fix of the moptilities/closer-mop problem, which happens on already deployed versions of ASDF which we can not undeploy or fix. moptilities/closer-mop authors can negoticate one o
As for semantic versioning, it is good to distinguish API compatible changes from API incompatible, I fully agree.
But my point - it's not enough to just bump major version number, as semantic versioning suggests.
If author of "somelib" library wants to make an API incompatible change, it is better to release new ASDF system "somelib2" and put code into new package somelib2.
Consider a use case: my-application depends on library-a 1.0.0 and library-b 1.0.0. Both library-a and library-b depend on some basic-lib, version 1.0.0.
Now basic-lib author makes incompatible change, and bumps version to 2.0.0. Library-a 1.1.0 adopts basic-lib 2.0.0 while library-b remains unchanged.
Result: my-application is broken, because it now depends on basic-lib 2.0.0 and basic-lib 1.0.0.
I think the approach of breaking API and informing others about via changed version number is inadequate.
We should try to never break API compatibility. Once we released something as library-a and its API is used by others, it is desirable that the thing named library-a fulfilled that API forever.
In the above example, if the basic-lib author released the incompatible descendant as basic-lib2 with code moved to package basic-lib2, then my-application could load basic-lib and basic-lib2 and they peacefully coexist in the same lisp image.
I think this approach is the best in 90% of cases.
Best regards, - Anton