0.8.19.37:

        Increment +fasl-file-version+. It just wouldn't feel like a real
        SBCL release without invalidating the fasls.

        * Some FFI-related fasls became incompatible at about 0.8.19.26.
          Probable cause: "lazy alien resolution improvements".

diff --git a/src/code/early-fasl.lisp b/src/code/early-fasl.lisp
index a5b95e6..5729c6c 100644 (file)
--- a/src/code/early-fasl.lisp
+++ b/src/code/early-fasl.lisp
@@ -76,7 +76,7 @@
 ;;; versions which break binary compatibility. But it certainly should
 ;;; be incremented for release versions which break binary
 ;;; compatibility.
-(def!constant +fasl-file-version+ 52)
+(def!constant +fasl-file-version+ 53)
 ;;; (record of versions before 2003 deleted in 2003-04-26/0.pre8.107 or so)
 ;;; 38: (2003-01-05) changed names of internal SORT machinery
 ;;; 39: (2003-02-20) in 0.7.12.1 a slot was added to
@@ -111,6 +111,9 @@
 ;;; 51: (2004-07-24) Package locks (SBCL 0.8.12.7) changed signature of
 ;;;     %DEFPACKAGE.
 ;;; 52: (2004-11-02) Merge of SB-UNICODE.
+;;; 53: (2005-02-22) Something introduced in SBCL 0.8.19.26 (give or take
+;;;     a couple of patches) invalidated some FFI-related fasls. Probably
+;;;     caused by "lazy alien resolution improvements".
 
 ;;; the conventional file extension for our fasl files
 (declaim (type simple-string *fasl-file-type*))

diff --git a/version.lisp-expr b/version.lisp-expr
index 7a54542..c9fe506 100644 (file)
--- a/version.lisp-expr
+++ b/version.lisp-expr
@@ -17,4 +17,4 @@
 ;;; checkins which aren't released. (And occasionally for internal
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.19.36"
+"0.8.19.37"