;;; versions which break binary compatibility. But it certainly should
;;; be incremented for release versions which break binary
;;; compatibility.
-(def!constant +fasl-file-version+ 43)
+(def!constant +fasl-file-version+ 48)
;;; (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
;;; recent maintenance, e.g. from (VECTOR NIL)-as-string support.
;;; (And experimental results suggest that compatibility was broken
;;; between about 0.8.1.29 and 0.8.1.39.)
+;;; 44: (2003-08-25) various changes leading up to 0.8.3
+;;; <dan`b> what happened this month to stalate the fasls?
+;;; <Krystof_> I think I renumbered everything again
+;;; <Krystof_> simple-array-unsigned-byte-7, probably
+;;; <Krystof_> (thanks to pfdietz)
+;;; 45: (2003-10-02) I (WHN) incremented the version for the 0.8.4
+;;; release because I couldn't immediately convince myself that
+;;; .fasl files could never possibly ever refer to the SB-C
+;;; CONTINUATION-related data types which were changed
+;;; incompatibly in 0.8.3.62.
+;;; 46: (2003-11-11) Tim Daly, Jr. (and Christophe Rhodes) reported
+;;; .fasl incompatibility on sbcl-devel 2003-11-09.
+;;; 47: (2003-11-30) Static variables were rearranged in 0.8.6.11.
+;;; 48: (2004-03-01) Renumbered all the widetags to allow for more
+;;; microefficiency in sbcl-0.8.8.10
+
;;; the conventional file extension for our fasl files
(declaim (type simple-string *fasl-file-type*))