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