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