[asdf-devel] In defense of ASDF & Semantic versioning
avodonosov at yandex.ru
Tue Nov 19 19:29:03 UTC 2013
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.
More information about the asdf-devel