UNSUPPORTED-FUNCTIONALITY Error [was Re: Version 3.1.7.7 has been pushed]

[Elias Pipping]

Dear Faré,

> On 26 Aug 2016, at 13:42, Faré <fahree at gmail.com> wrote:

I’ll chime in here because I believe this criticism is targeted at what I was proposing.

> What next? Have each error message include a matrix of which ASDF
> version supports which interface with which bug fix on which versions
> of which implementations? Including future versions? That's complete
> madness.
> 
> If you believe some power users care about such details, a more
> future-proof way, once again, is to include a short URL in the error
> message, and maintain your compatibility matrix there.
> 
> If you're only trying to report version numbers, there's
> implementation-identifier and asdf-version for that, and I don't see
> any reason to decorate some error messages with that and not others.
> 
> As for testing ASDF, we have asdf-test:with-expected-failure to keep things sane
> and #+ and leave-lisp to skip meaningless tests.

I agree that my proposal would take us on a path towards a lot of effort (even though I think much of such effort could be automated, and my hope would be that through regression testing and bug reports to upstream, the list of x-does-not-work-on-y would decrease in size after a while again as we stop to support older versions). So here’s a rather radical counter-proposal:

For any free and open-source lisp that we seek to support, we only test the most recent release. If the feature is broken or unavailable on that version of that lisp or we simply haven’t gotten around to implementing the necessary glue code yet, we use #+that-lisp to indicate an error. In particular, we never even need to check the version of a lisp in asdf/uiop: If a user runs an different version of said lisp, it’s up to him or her to check if everything works as intended. With each release of asdf/uiop, we consequently need to record the list of most recent releases we tested with. As a bonus, we may or may not provide additional information in a feature matrix or as plain text online (e.g. in the gitlab wiki).

In particular, 
 - If a bug is fixed in a lisp but the fix hasn’t made it into a release of that lisp yet, that info might go on the wiki, but the uiop/asdf code will remain as-is. We only touch it once there’s a release of that lisp (or put feature branches in place that we merge at the appropriate time).
 - If a bug occurs in an older version of a lisp, that information, too, might go on the wiki, but no effort will be made to work around the bug in asdf/uiop. Such bug reports would be consequently be closed as won’t-fix.

For any lisp that’s not free and open-source, we might want to take additional steps in order to support the previous major release; both for Allegro CL and LispWorks there are corresponding reader macros, so that resulting code should register rather low on the insanity scale, even with such additional support.


Elias