On 9/1/16 Sep 1 -9:57 PM, Sam Steingold wrote:
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 18:38:12 -0500]:
On 9/1/16 Sep 1 -6:15 PM, Sam Steingold wrote:
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 12:34:11 -0500]:
Even worse, AFAICT clisp does not make its version number available to the lisp context.
CLISP, like all the other implementations striving for ANSI CL compliance, exports `lisp-implementation-version' (http://clhs.lisp.se/Body/f_lisp_i.htm).
However, testing version numbers is not the best way to achieve cross-release compatibility; it is much better to test for specific behavior.
True, but this is not for code -- it's for regression testing. For regression-testing, I think it's fine if we say "on clisp, if the version is less than or equal to 2.49, disable this test."
Until now we have just been saying "on clisp, disable this test."
Unfortunately, since I believe that clisp in git has not been bumped beyond 2.49, reading LISP-IMPLEMENTATION-VERSION may not solve our problem.
lisp-implementation-version does provide the information you seek. the released version is 2.49, the development is 2.49+. we use hg, not git.
https://sourceforge.net/p/clisp/clisp/ci/default/tree/version.sh
OK. Sorry -- I realize I am being fussy, but it's a lot easier for us if we can have something like
(version>= (clisp-implementation-version) "2.49.0")
which works as do all ASDF version numbers, on the \d+ (. \d+)* pattern.
If we have to wrestle with clisp's "2.49+" and someone else's "2.50rc" and someone else's "2.50beta3", it's just crazy-making and unsustainable.
If there is another standard that people are adhering to, I'd be interested in ASDF supporting it, but not one version numbering scheme per implementation. Well, it's not the scheme per se, it's the need for us to maintain a >= relationship for each such scheme.