ASDF components are brittle for backwards compatibility

Thu Apr 29 17:11:38 UTC 2021

> On 29 Apr 2021, at 11:42, Stelian Ionescu wrote:

>> How can ASDF or a developer determine that the unknown property doesn't change the semantics of the DEFSYSTEM, and therefore discarding it would have an effect that's contrary to the author's intention ?

>> ASDF has no syntactic distinction between properties that affect the compilation process and mere annotations like author, licence, etc...

> You can safely assume that the unknown property doesn't change the semantics, because if it does, then the system must require a particular version of ASDF.

Yes but you can't assume that the system author specified the minimum ASDF version correctly.
Developers currently have no way of figuring out what is the actual minimum required version, and version guards are rare and the result of guesswork (including those I put in the libraries I maintain).

> In other words, this does not introduce a failure mode that isn't already present. If there's a `:use-apple-clang` property introduced in ASDF 29.7 and you didn't put some requirement for ASDF >= 29.7 then your system is busted whether the user discards and continues or not -- the library developer has erred, and nothing about this new extensibility makes the problem worse.

> But it *does* make it possible to extend ASDF *in safe ways* without compromising backwards compatibility.

> Note the "in safe ways" -- if we added new properties that change the semantics, we must do something to protect people using older versions. The proposed capability wouldn't change that one way or another. It just makes it possible to extend metadata without excessive pain.

Instead of dedicating much work to ensuring that newer DEFSYSTEMs work with old ASDF versions, we should make it clear that one should just update ASDF frequently.

--
Stelian Ionescu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20210429/f07bfb81/attachment-0001.html>