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

Faré fahree at gmail.com
Mon Nov 18 15:45:26 UTC 2013


On Mon, Nov 18, 2013 at 10:21 AM, Pascal Costanza <pc at 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



More information about the asdf-devel mailing list