> It's kind of impressive that Common Lisp is the only language I use where I can't expect code written today to work next month due to Quicklisp lacking versioning outside of the date attached to dists.
I think the lack of version pinning is a positive force in stability: reducing the pain of breaking changes increases the likelihood that library authors will break things.
This seems to be the widely reported experience from people who develop in Common Lisp daily or very frequently, and even in my haphazard development I find things pretty stable. And it's not like version pinning is all that helpful in a living project anyway, because you often want to update things, and I notice my JavaScript-using friends constantly suffering from breakages every time they try.
With Lisp, I setup my libraries in jenkins to pull the latest SBCL and quicklisp distro once a month and run tests, it's pretty rare for things to break. Once or twice something with an SBCL release itself, once with a bug involving the interplay of two of Fukamachi's libraries. The SBCL one was noticed by others and fixed pretty quickly, for the library one I was able to use git-bisect to easily find the breaking commit and apply a local fix while I waited for the issue I filed to get addressed. This was during Fukamachi's life-threatening illness period, even, but an alternative maintainer did address the bug on their side. The only annoyance these days is Xach is suffering from who knows what preventing the quicklisp distro from updating since October, and there hasn't been communication with people offering to help, so it's forcing everyone to pull projects in locally (and qlot does help with that) for updates or use an alternative.
I think the lack of version pinning is a positive force in stability: reducing the pain of breaking changes increases the likelihood that library authors will break things.