-(defconstant +fasl-header-string-stop-char-code+ 255)
-
-;;; This value should be incremented when the system changes in such
-;;; a way that it will no longer work reliably with old fasl files.
-(defconstant +fasl-file-version+ 15)
-;;; 2 = sbcl-0.6.4 uses COMPILE-OR-LOAD-DEFGENERIC.
-;;; 3 = sbcl-0.6.6 uses private symbol, not :EMPTY, for empty HASH-TABLE slot.
-;;; 4 = sbcl-0.6.7 uses HAIRY-DATA-VECTOR-REF and HAIRY-DATA-VECTOR-SET
-;;; when array headers or data element type uncertainty exist, and
-;;; uses DATA-VECTOR-REF and DATA-VECTOR-SET only for VOPs. (Thus,
-;;; full calls to DATA-VECTOR-REF and DATA-VECTOR-SET from older
-;;; fasl files would fail, because there are no DEFUNs for these
-;;; operations any more.)
-;;; 5 = sbcl-0.6.8 has rearranged static symbols.
-;;; 6 = sbcl-0.6.9, got rid of non-ANSI %DEFCONSTANT/%%DEFCONSTANT stuff
-;;; and deleted a slot from DEBUG-SOURCE structure.
-;;; 7 = around sbcl-0.6.9.8, merged SB-CONDITIONS package into SB-KERNEL
-;;; 8 = sbcl-0.6.10.4 revived Gray stream support, changing stream layouts.
-;;; 9 = deleted obsolete CONS-UNIQUE-TAG bytecode in sbcl-0.6.11.8
-;;; (somewhere in here also changes to AND and OR CTYPE layouts)
-;;; 10 = new layout for CONDITION in sbcl-0.6.11.38
-;;; 11 = (a) new helper functions for MAKE-LOAD-FORM (HASH-TABLE) in
-;;; sbcl-0.6.12.11
-;;; (b) new address space constants for OpenBSD in 0.6.12.17
-;;; (doesn't need separate version from (a) because the
-;;; OpenBSD port was broken from sometime before 0.6.12.11
-;;; until the address space was changed)
-;;; 12 = sbcl-0.6.12.22 added new SB-FASL package
-;;; 13 = sbcl-0.6.12.28 removed some elements from *STATIC-SYMBOLS*
-;;; 14 = sbcl-0.6.12.29 removed more elements from *STATIC-SYMBOLS*
-;;; 15 = sbcl-0.6.12.33 changed the layout of STREAM
-
-;;; the conventional file extension for fasl files on this
-;;; architecture, e.g. "x86f"
-(declaim (type (or simple-string null) *backend-fasl-file-type*))
-(defvar *backend-fasl-file-type* nil)
-
-;;; This is a sort of pun that we inherited from CMU CL. For ordinary,
-;;; non-byte-coded fasl files, the "implementation" is basically the
-;;; CPU. For byte-coded fasl files, the "implementation" is whether
-;;; the data are stored big-endianly or little-endianly.
-(defun backend-byte-fasl-file-implementation ()
- *backend-byte-order*)
+(def!constant +fasl-header-string-stop-char-code+ 255)
+
+;;; This value should be incremented when the system changes in such a
+;;; way that it will no longer work reliably with old fasl files. In
+;;; practice, I (WHN) have often forgotten to increment it for CVS
+;;; versions which break binary compatibility. But it certainly should
+;;; be incremented for release versions which break binary
+;;; compatibility.
+(def!constant +fasl-file-version+ 42)
+;;; (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
+;;; DEFSTRUCT-SLOT-DESCRIPTION
+;;; 40: (2003-03-11) changed value of (SXHASH NIL)
+;;; 41: (2003-04-26) enforced binary incompatibility between +SB-THREAD
+;;; and -SB-THREAD builds
+;;; 42: (2003-05-22) %NAME slot changed to NAME in
+;;; DEFSTRUCT-SLOT-DESCRIPTION
+
+;;; the conventional file extension for our fasl files
+(declaim (type simple-string *fasl-file-type*))
+(defvar *fasl-file-type* "fasl")