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

[Robert P. Goldman]

Faré wrote:
>> As for signalling the problem, I agree with Robert in the sense that
>> > if such users exists, it is friendly to save them from debugging an issue like this.
>> >
>> > If not error, then at least very very bold warning, or cerror
>> >
> 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.

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.  Many people
get ASDF updated only when their implementations update the bundled
ASDF, and those implementations often do not trumpet such updates.
Furthermore (although I have an as yet uncommitted partial draft), the
current manual provides no support for programmers grappling with such
problems.

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."

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.

Best,
R