On 10/11/15 Oct 11 -12:14 PM, Faré wrote:
On Sun, Oct 11, 2015 at 12:57 PM, Robert Goldman rpgoldman@sift.net wrote:
On 10/10/15 Oct 10 -10:26 AM, Faré wrote:
On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
If you are interested, this version of ASDF fails on SBCL 1.0.58:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}>
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
I'll let Robert decide whether it's OK to drop support for SBCL releases older than that.
I'd weakly vote "yes, it's OK to stop supporting things more than 2 years old", but that's just me.
I agree. I believe that it's appropriate. I'd be willing to see us drop support for the 1.1.x series, for that matter. IMO it's easier to keep track of "1.1 is unsupported" than try to remember which monthly release in particular is unsupported. Agreeable policy?
Question for someone more knowledgeable: is there a brief explanation of the difference between 1.1 and 1.2 SBCLs? What triggered the bump of minor version?
Considering that the propagation latency for ASDF itself is about 2 years, it might be a bad idea to drop support for things that are only a bit over a year old (sbcl 1.1.18, last in the series). That said, it's true that SBCL upgrades ASDF about every year, so that makes more sense. Still. I would say that 2 year old is probably a better rule of thumb.
The problem with this rule of thumb is that it requires the ASDF maintainer (me) to track SBCL releases and be able to map release numbers to dates. I don't like that. It's more work and cognitive load that I really don't have room for.
Given that some version of 1.1.x of SBCL can no longer be supported, I'd prefer to write off all of 1.1
Cheers, r