[asdf-devel] Pushed version 3.1.0.52 -- first version with checks for OPERATION subclasses -- please test!

[Faré]

>> It's nice to notify users of problems... but what if this is done by
>> introducing new problems for sure, whereas these users are
>> hypothetical, especially since they are supposed to have extended ASDF
>> yet been unaware of change introduced one year ago in ASDF?
>
> I understand your concern, but I wish you would stop using the term
> "hypothetical" here.  The concern is not hypothetical, since I have
> encountered it myself.  Handling the upgrade cost us at least four
> person days, only terminating when I thought to ask you a related question.
>
I'm sorry about that, and sad I didn't advertise the issue loud enough
(I tried, but the signal probably got drowned into all the other issues
that had to be addressed.)

Still, whether any *remaining* code afterwards remains is hypothetical.
One (costly) alert after a year — how many other alerts in the years to come?
What are the odds someone went into deep ASDF extension hacking,
but never bothered to check the asdf-devel mailing-list or be subscribed to it,
nor to upgrade his ASDF and test his software?
Is such person worth some backward incompatible change?
Fifty bucks here say this person doesn't exist and/or will never touch
Lisp again
to notice the breakage and complain about it.

> While it is desirable that they do so, expecting people to track ASDF
> development is not a reasonable expectation, any more than it is
> reasonable to expect people to track developments in make.
If make had an extension mechanism, it would be reasonable for authors
of extensions to touch base within a year after a major version change.

> Furthermore (although I have an as yet uncommitted partial draft), the
> current manual provides no support for programmers grappling with such
> problems.
>
The manual is severly lacking. I improved it tremendously, with your help,
but it's still quite incomplete and less useful than it could be.
Compatibility with a moving target make it harder to write the manual
in a simple understandable style.
I believe references to compatibility with ASDF 1 can be removed;
hopefully, after LispWorks and Quicklisp adopt ASDF 3,
notes for compatibility with ASDF 2 can soon be retired, too.

> I am willing to do what I can to minimize the dislocation by trying
> methods other than the alternative I have pushed to the repository.
>
> The one thing I am not willing to do is to release another ASDF 3
> without a programmatic warning to users of new OPERATION subclasses that
> the semantics of OPERATION has changed from "implicitly
> downward-propagating dependencies" to "not propagating any dependencies."
>
NB: not just downward, but also sideway, and even selfward (for the
input-files method).
All used to be implicit. None is now.

> I would like us to focus on the issue of minimizing the number of these
> warnings that are false positives, rather than continuing to argue for
> their complete removal.  E.g., in cases where we know that a new
> OPERATION subclass is safe (see Faré's earlier survey of quicklisp
> libraries), we could whitelist it.  But I don't have time for further
> discussion of shipping a new ASDF without some warning.
>
I was trying to avoid whitelisting, especially since older variants of
the same libraries might be in the wild, and incompatible.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If debugging is the process of removing bugs,
then programming must be the process of putting them in.
        — Dijkstra