[asdf-devel] has ":depends-on ((:version ...))" semantics changed?

[Faré]

> Anton Vodonosov wrote:
>> So, my question is: how :depends-on ((:version ...))
>> should work, and is the change in the behavior intentional?
>
The change of behavior in VERSION-SATISFIES is from ASDF 3.0.1, 2013-05-16.

Since even before VERSION-SATISFIES was introduced on 20/02/2002, ASDF
had been considering that different major version number signified
incompatibility. I lifted that restriction, and made the check be the
simple lexicographic order comparison it otherwise was, after parsing.
Parsing is still separating the version into a list of non-negative
integers; leading zeroes don't count.

The reason for the change is that when releasing ASDF 3.0.0, we found
that this caused an issue with ASDF itself considering that it was not
compatible with ASDF 2; therefore Quicklisp considered ASDF 3.0.0 was
not an adequate replacement for ASDF 2.26, and tried to load ASDF 2.26
on top of ASDF 3.0.0, with catastrophic results. Therefore, after
briefly consulting the ASDF user base, and checking that not one of
the quicklisp projects was positively relying on the old behavior, I
quickly released a new ASDF 3.0.1, where a greater major version
number only means more awesomeness in a compatible way.

It seems that the old behavior had never been documented, except for
the source code itself, and its being mentioned on this mailing list
when the semantics of versions was previously discussed. Hence no one
relying on it.

Apologies for the breakage.


On Sun, Nov 17, 2013 at 9:01 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
> There are two different version requirements.
>
> :version is supposed to be "this is the version I need."  It treats
> changes in the highest version component as API-changing modifications
> that don't satisfy requirements for mismatching major components.
>
> When we advertise Closer-MOP 1.0.0, we are saying that we have made
> changes to the API, so it's different from 0.x.  Hence a :VERSION
> dependency of 0.55 is not satisfied by 1.0.0, although it IS satisfied
> by 0.61
>
> If major changes are going on in a library's API, then they should be
> noted by the library developer, and people who use this library have to
> think about those changes.  This is unavoidable and better than dealing
> with versioning systems like where you never know when a library's API
> has changed, and your code may break at the slightest version bump.
>
> Actually I think that the code may have changed to be more permissive at
> some point.  I believe that originally a requirement of, e.g., 0.0.7
> would not be satisfied by 0.1.0 (although it would be satisfied by 0.0.9).
>
> The good news is that ASDF's version numbering scheme has a semantics
> that can provide useful support to programmers.  The bad news is that
> not enough people know about this semantics, so it doesn't provide as
> much value as it might.
>
Robert correctly describes the old behavior of ASDF 1 & 2, that was
discontinued in ASDF 3.

Dan Barlow was obviously inspired by the number versioning of Linux
shared object libraries. It seems this wasn't how the CL community
started using these version numbers. And the match was probably not
that great: Linux .so's involve object-level compatibility, whereas
ASDF dynamic loading involves source-level compatibility, where
compatibility if desired can be handled with #+ and #. and
conditionals with find-symbol or fboundp. Meanwhile, we use
output-translations to deal with object-level incompatibilities.
Overall, the old behavior of version-satisfies is not to be regretted,
and the new maintainer may once again consider adopting (or not) the
rpm or debian or whatever other version comparison mechanism (in which
case I can submit code I once wrote). But hey, Dan Barlow was a great
experimenter; some of his experiments failed, others succeeded
brilliantly; thanks Dan.

> One thing that might make everyone's lives easier would be making the
> MISSING-DEPENDENCY-OF-VERSION error a continuable error instead of a
> fatal one.  What would you think about this?
>
That can do it. On the other hand, if the author inserted a :version
requirement, he probably had a good reason, and it's therefore vain to
try to override it, rather than upgrade the library.

PS: unrelatedly, there has been a lot of action on ASDF since 3.0.3:
* There is my package-system one-package-one-system-per-file support,
compatible with quick-build and similar to faslpath.
* A lot of UIOP fixes, notably as it's now being used in the Google
build system (short-circuiting the asdf/defsystem itself, instead
using a converter from ASDF to the native system to which Lisp support
was added).
* ASDF will soon support GCL (Camm Maguire has released 2.6.8 and
2.6.9 and is now actively fixing the bugs in GCL that prevented ASDF
from running, while I've been modifying ASDF itself).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Never explain. Your friends do not need it and your enemies will
never believe you anyway.
        — Elbert Hubbard