[asdf-devel] In defense of ASDF & Semantic versioning

[Robert P. Goldman]

Anton Vodonosov wrote:
> 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

Absolutely.  That's why I trimmed those parts of your email from my
reply and changed the subject line.

> 
> 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.

I see your point here, but I think it's too radical.  It's like having a
purely functional programming language with no garbage-collection!  We'd
be left with heaps of unmaintained and unmaintainable versions of
basic-lib floating around in the worse case.

Also, the two different libraries won't live happily in the same lisp
image, unless they change package at every release (or we all adopt Ron
Garret's lexically-scoped namespaces).

This approach seems like it will be such a monumental pain for the
library maintainers, and anyone who wishes to upgrade his/her client
program from basic-lib to basic-lib2, that it's unrealistic.  [Indeed,
some would say even my more modest semantic versioning proposal is too
unrealistic!]

I'd argue that having two versions of the same library *in the same
image* is too demanding a target.  But two versions of the same library
on the same machine is quite feasible, and indeed I do this myself,
every day.  I have different source trees for different projects, and
with each source tree is associated a different ASDF configuration.

This is not a futuristic "wouldn't it be nice if..." situation, either:
it's a simple requirement of my daily work environment.  E.g., I have
projects that rely on different versions of FiveAM (they are hosted
differently, so it's not just a matter of demanding that everyone
upgrade -- some I run, some I don't).

Best,
r