wanted: sbcl version assert

[William Halliburton]

Several times in my working with other people, since I am keeping up
to date with SBCL, when I have them pull my latest code we go through
a cycle of:

them: "I'm getting error xyz."

me: "Oh, you need to update to the latest SBCL."

So I wrote the following in my initialization file. I'm wondering if
there is a place for this or something like it in the main code
base. If so, please review and I can clean it up as needed.

Also, if this launchpad system is not the best place for things like
this and the sbcl-devel list would be better, please inform me of my
transgressions.

----

(defparameter *required-sbcl-version* "1.0.44.22")

(defun split-sbcl-version (str)
  (flet ((list-to-num (list)
           (parse-integer (coerce (nreverse list) 'string))))
    (loop with acc and vals
          for c across str
          do (if (digit-char-p c)
               (push c acc)
               (progn
                 (push (list-to-num acc) vals)
                 (setf acc nil)))
          finally (return (cons (list-to-num acc) vals)))))

(defun sbcl-version-as-number (str)
  (destructuring-bind (d c b a) (split-sbcl-version str)
    (+ (* a 1000000000000)
       (* b 100000000)
       (* c 10000)
       d)))

(let ((this-version (lisp-implementation-version)))
  (when (< (sbcl-version-as-number this-version)
           (sbcl-version-as-number *required-sbcl-version*))
    (format t "SBCL version of at least ~A is required. This SBCL is ~A.~%"
            *required-sbcl-version* this-version)
    (quit)))

[Nikodemus Siivola (nikodemus)]

Launchpad is fine.

In principle I think SB-EXT:VERSION< or similar would be possible.

It does need to deal with non-numeric components, but probably TRT is the right thing to only parse the leading numeric components.

So

  (version< "1.0.34.12-foo" "1.0.44.1.master.0-dirty") => T

and

  (version< "1.0.42.debian-something" "1.0.42.debian-something-other") => NIL

. Or possibly use STRING< to compare non-numeric tails. Dunno.

While there's no strict need to have this in SBCL itself, obviously, SBCL _is_ a sufficiently moving target that it might be a good thing.

[Philip Munksgaard (pmunksgaard)]

Wouldn't it make more sense to call it sb-ext:version<=, since i imagine we would want (version<= "1.0.42.debian-something" "1.0.42.debian-something") to return T?

[Philip Munksgaard (pmunksgaard)]

The attached patch adds SB-EXT:VERSION-ASSERT.

It takes a version number as a string, and asserts that (lisp-implementation-version) is equal to or greater than the given version.

I've chosen to only parse leading numerical components in the version strings and ignore anything after the numerical components stop. Trying to make sense of whether a bunch of letters are some kind of versioning scheme (1.1.12a vs. 1.1.12b), a designator for release candidates (1.1.12rc1), a specific git commit or branch (1.1.12.14-b2ed34b-dirty), distribution-specific (1.1.12-debian) is futile.

Thus, as soon as version-assert encounters a non-digit character that isn't a period in either the version-string or (lisp-implementation-version), it stops parsing any more. Beyond that it pretty much works as expected:

If the current version is 1.1.12, (version-assert "1.1.12") passes.
If the current version is 1.1.12, (version-assert "1.1.12.1") does not pass.
If the current version is 1.1.1, (version-assert "1.0") passes.

[Philip Munksgaard (pmunksgaard)]

It seems that ASDF3 actually includes functions that do this:

uiop:version<
uiop:version<=
uiop:version-compatible-p

[Paul Khuong (pvk)]

I pushed similar in 920b5eb (New function SB-EXT:ASSERT-VERSION->=). Thank you for the initial patch!