Testing Quicklisp with ASDF
rpgoldman at sift.net
Wed Sep 20 19:39:26 UTC 2017
On 20 Sep 2017, at 13:41, Anton Vodonosov wrote:
> If the motivation is only this, IMHO it's a difficult approach to
> backward compatibility - you go online and find all usages, create
> pull requests, try to contact developers to have the fixes merged. If
> you don't find all usages (somebody's application not published
> online), then it will break after the change.
> If there is no difficulty keeping the old functions in the code base,
> I would leave them forever (for course deprecated).
> Just my opinion.
> 18.09.2017, 00:52, "Faré" <fahree at gmail.com>:
>> On Fri, Jun 2, 2017 at 2:14 AM, Anton Vodonosov
>> <[avodonosov at yandex.ru](<mailto:avodonosov at yandex.ru>)> wrote:
>>> I mean is it impossible to keep existing forever (implemented in
>>> terms of the new, better API)?
>> Some functions have a horrible API that is error-prone or misdefined
> and should NOT be used by anyone when better APIs are available.
> RUN-SHELL-COMMAND is a case in point — that horrible function must
> die, it's a security nightmare as well as a usability absurdity.
> SYSTEM-DEFINITION-PATHNAME was historically doing the wrong thing; we
> provide an approximation of what it used to do in terms of supported
> interfaces, but the only way to be sure that the user doesn't mean
> something crazy in terms of the old meaning is to migrate to the new
> —♯ƒ • François-René ÐVB Rideau
> Good girls are bad girls that never get caught.
I'm willing to do this up to a certain level. But beyond a certain
point, we can't maintain code that's cluttered with stuff that we no
longer understand or that does the wrong thing. If there's something
really wrong, at a certain point, I will need to say "I'm the ASDF
maintainer, not the Quicklisp maintainer," and be willing to break
things. Particularly things that are un-maintained.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asdf-devel