SBCL support [Was: Re: Towards release 3.1.6]
Robert Goldman
rpgoldman at sift.net
Wed Oct 14 22:55:17 UTC 2015
On 10/11/15 Oct 11 -12:14 PM, Faré wrote:
> On Sun, Oct 11, 2015 at 12:57 PM, Robert Goldman <rpgoldman at 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 at 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
More information about the asdf-devel
mailing list