If we ask what was Spice Lisp based on, I don't know if it used sources from a prior Lisp. Though there was an earlier C-MU Lisp, which was based on UCI Lisp, Stanford LISP 1.6,... Generally Spice Lisp was in the Maclisp camp.
Worth noting is that according to the Download page[1], only amd64 linux has had 2.0 binaries released. None of the other platforms has it yet (so macOS and Windows doesn't [yet])
My package manager installs version 1.4. I downloaded the version 2.0 package from the website, and ran the "install.sh" script per the Getting Started instructions for installing a binary. When I tried running it I got the following error:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /usr/local/bin/sbcl)
I couldn't find a "make.sh" file in the package that I downloaded, and I'm not enough of an expert to solve the GLIBC version error problem.
make.sh is included in the source release [0]. Download that, not the binary release. The binary release is only needed for either bootstrapping or for a compatible binary installation. (Evidently your glibc isn’t compatible with the binary release; building from source should be as easy as I suggest above.)
Once you install it, you can uninstall your system-provided SBCL.
There is no commitment to semver from SBCL's side. Rather, it's trying to follow calendar years with at least one release each of the 11 months and a major release in the end of the year.
Uh, I take it back then. I get this versioning scheme for something that don't have a reasonably application for semver like an operating system for instance, but a programming language? I don't really see the point. If you go that way you might as well tag it "SBCL 2020" or something like that to make it clear.
But I suppose that's pure bikeshedding and it doesn't really matter.
Is that feasible? Last I used Common Lisp, I seem to recall the spec being rather ambiguous on a number of important practical points, so any real program couldn't depend on only CLTL2.
For example, Maxima lists a number of implementations that can compile it, and says "Ports to other ANSI Common Lisps should be straightforward and are welcome" [1]. The source code is full of #+ #- conditionals.
ANSI CL is a spec of the language. Programs like Maxima use a lot of features not covered by the language specification and Maxima has been written over a long time and has to deal with changing languages, operating systems and implementations, too.
For example the Common Lisp standard does not say anything about how an executable can be created. Maxima surely want s to do that. There are mow also libraries, which provide common interfaces for a bunch of general cases, though.
I write a lot of CL, and it’s reasonably easy to write standard-conforming code that just works across multiple implementations and, if you need something not standardized like sockets, TLS, or threads, there are fairly high-quality and “standard” portability libraries that make it easy to avoid reader conditionals most of the time.
The not-really-breaking change is not actually related to the version number. There is approximately 0% chance that somebody depends on the presence of that symbol in features. And there have been more actually noticeable compatibility changes with minor version bumps.
