This is caused because in older ASDF, a version of 1.<whatever> was not considered to satisfy a version requirement of 0.<whatever>. This was changed because ASDF updated to 3.0 but was not considered satisfying 2.<whatever> as required by Quicklisp.

http://thread.gmane.org/gmane.lisp.asdf.devel/3062/focus=3066 has some info about when and why this was changed.

Zach

Pascal Costanza pc@p-cos.net writes:

Hi,

I’m the maintainer of Closer to MOP, and I have just updated the version numbers as you describe below. If I made a mistake and chose a numbering scheme that confuses ASDF, please let me know, and I will fix this. However, I believe what I chose is in line with the ASDF documentation.

Previously, the version numbers for Closer to MOP lacked a third entry (“patch version”), maybe this is a confusing change?

Pascal

On 17 Nov 2013, at 10:34, Anton Vodonosov avodonosov@yandex.ru wrote:

...

Hello.

Has the semantics of :depends-on with :version specified for the dependency changed recently?

I am asking, because I observe problems in several libraries.

For example, moptilities.

moptilities.asd has :depends-on ((:version :closer-mop "0.55"))

In Quicklisp 2013-11-11 closer-mop is updated, now its ASDF system has :version "1.0.0"

Now moptilities fails to load on many lisps (clisp, ccl-1.8, ccl-1.8, ecl, sbcl-1.1.0.36).

The error is MISSING-DEPENDENCY-OF-VERSION: Component :CLOSER-MOP does not match version 0.55, required by #<SYSTEM "moptilities">

But on sbcl-1.1.11 moptilities load OK. This is a relatively recent SBCL, so I assume it has newer ASDF than many other lisps. And probably that's why it it can load moptilities.

Also interesting, that in the previous Quicklisp closer-mop version was "0.61". And moptilities, which depend on closer-mop "0.55" was loaded successfully by many lisps which now fail.

Test results for moptilities for the current and previous Quiclisp may be found here: http://common-lisp.net/project/cl-test-grid/library/moptilities.html

Moptilities is only on example, there are other libraries affected by this problem.

So, my question is: how :depends-on ((:version ...)) should work, and is the change in the behavior intentional?

Best regards,

• Anton

-- Pascal Costanza

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

On Sun, Dec 8, 2013 at 5:15 PM, Anton Vodonosov avodonosov@yandex.ru wrote:

18.11.2013, 07:13, "Faré" fahree@gmail.com:

...

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.

Could you shed some light on this? I sometimes want such system for myself. Are there any examples how you do it?

I admit it's under-documented at this point, but lisp-interface-library provides an example.

It's very similar to quick-build (and maybe compatible, modulo a separate configuration), and also very similar to faslpath (except using / rather than . as a separator in package names): you configure the top of your hierarchy with an asd file with a defsystem form that specifies :class package-system, then each file under that hierarchy is a subsystem with a trivial mapping of system name, pathname, and package name. The cl:defpackage or uiop:define-package form at the start of each file specifies the dependencies via the same trivial mapping.

PS: it looks like development of asdf has stabilized. Maybe we should get into testing mode before to release ASDF 3.1.1?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org <hcf> information we gather and create overflows our means of managing it <hcf> our ppl r only happenstancely synergistic

18.11.2013, 07:50, "Robert P. Goldman" rpgoldman@sift.info:

Are you saying now that version 1.0.0 of Closer-MOP will satisfy the requirement of 0.55, and that Anton should *not* be having this build failure.

Robert, build failures happen on older ASDF, and not happen on newer ASDF.

On Mon, Nov 18, 2013 at 2:34 AM, Pascal Costanza pc@p-cos.net wrote:

The 0.xy versions of Closer to MOP were not based on semantic versioning, but on an ad hoc versioning scheme. 1.0.0 did not change any API at all, so is definitely compatible with the last 0.xy versions. 1.0.0 is supposed to acknowledge the maturity of the library, that's it.

The FAQ section at http://semver.org seems to suggest that exceptions to the rules are acceptable, and I believe that a change from ad hoc version numbers to semantic versioning is such an exception.

I'm open to suggestions for a better solution.

You're not proposing a solution. ASDF is not going to hard code an exception for your library. Though it's possible to override the ASDF default behavior, the library itself would have to do it, and there still needs to be an ASDF default, and the question is which.

The ASDF default changed in 3.0.1, for practical reasons having to do with an issue with ASDF itself, and making the smallest change during a crisis. It can change back (in which case a non-default class or initarg would be used for ASDF itself). The discussion is about what the default should be, and what should be the means to override it if necessary.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Thinking is the hardest work there is, which is probably the reason why so few engage in it. — Henry Ford

On Mon, Nov 18, 2013 at 10:21 AM, Pascal Costanza pc@p-cos.net wrote:

...

ASDF is not going to hard code an exception for your library.

Closer to MOP already existed before asdf imposed anything on version numbers, so asdf has to provide a way to define exceptions for such cases. The versioning scheme of Closer to MOP was ad hoc, because nothing existed that could have been adhered to. It must be possible for libraries to move from non-adhering to adhering in a smooth way. Frankly, I don't care how that's achieved. If I can solve this by adding something to the system definition, that's fine with me...

Did your library exist on 20/02/2002? Because that's when version-satisfies appeared with its ldo.so-like versioning semantics.

To go back to actually looking for a solution (which I understand you don't care for), we could either have subclasses of system with different methods on version-satisfies, or we could have a :version-satisfies slot in system, that defaults to one of 'version-compatible-p or 'version<= (for the old and new behavior respectively), and asdf itself would specify the current version<= behavior for itself if it isn't the default.

Note however that using either :class system-using-version<= or :version-satisfies version<= is not itself backward-compatible with old versions of ASDF, and so will have be protected with #+asdf3.1 or some such.

Personally, I wouldn't go through that trouble, and would stick to the current lexicographic-only version comparison, because I think the ld.so semantics don't really apply to source compatibility. But doing something is Robert's prerogative now.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everyone hates a martyr. It's no wonder martyrs were burnt at a stake. — E.W. Howe, "Country Town Sayings", p.7