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