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

Reply via email to