Dear lispers,

I'm looking for hackers to review my branch obsolete-function-warnings: https://gitlab.common-lisp.net/asdf/asdf/tree/obsolete-function-warnings

In it, I add support to UIOP for issuing conditions for obsolete functions, and use it for UIOP and ASDF deprecated functions. They can be style-warning, warning, continuable error or error, if possible at compile-time via a compiler-macro, or at first use at runtime. Last option is plain error at compile-time for having failed to delete the functions when promised.

There is also a cool but somewhat dangerous optional feature that can automatically bumps the status of an obsolete function at every release — you better not use it lightly.

Finally, this was the opportunity to realize that there are plenty of offenders in Quicklisp that use long obsolete APIs of ASDF and need be updated. Yikes.

QUESTIONS: * Does it make sense to go from :style-warning to :warning to :error to :delete ? * Does it make sense for :error to be a continuable error, or should I introduce an extra step for :cerror, then an :error that isn't continuable? * Robert is in charge of the release schedule, so he should decide what automatic bumping to use, if any. I suppose he may want style-warning now while we're in 3.1, then warning at 3.2, then error at 3.3, then function deleted in 3.4; except for some recently deprecated functions that should only start issuing style-warning in 3.2, and for some backward compatibility package munging that I hope can go away in 3.3. * At some point soon, someone must contact all those people using obsolete functions and classes, and chide them or offer patches. * Now is a good time to upgrade, since all maintained implementations at long last provide asdf3 (May 2013, so a 2 year delay from release to ubiquity; let's hope 3.1 will be ubiquitous next year).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "To speak algebraically, Mr. M. is execrable, but Mr. G. is (x+1)ecrable." — Edgar Alan Poe