On 3/17/16 Mar 17 -4:10 PM, Faré wrote:
No you can't, and I actually object to such a counter-productive feature EVER being made part of ASDF. It very much goes against the principle of ASDF configuration:
"THOU SHALT ALLOW EACH ONE TO CONTRIBUTE WHAT ONE KNOWS WHEN ONE KNOWS IT, AND THOU SHALT NOT EITHER REQUIRE OR ALLOW ANYONE TO CONTRIBUTE WHAT ONE DOESN'T ACTUALLY KNOW."
Declaring incompatibility with old versions you know is good. You've seen those versions, you know why trying to use them will cause headaches to whoever tries to use them (and to you when they come whining about it). So you forbid them. Users must use a newer version with fixes to known issues. Fewer headaches.
With all due respect, this is simply factually wrong, as I have illustrated in earlier emails and have seen in practice.
Here is a concrete case THAT HAPPENED TO ME:
1. XMLS had a bug that would cause it to crash when it read an XML file with processing directives. One of our systems, call it system A, needed this to be fixed.
2. I fixed XMLS to be robust to this, but at the cost of incompatibility in the API. I bumped the revision number to X.
3. System A recorded that it depended on XMLS version X.
4. Another system, call it System B, did not need this fix, and had an imminent delivery. This system relied on an XMLS version LESS THAN X. Note: The system B developers knew good and well -- in direct contradiction to your claim -- that they were incompatible with version X of XMLS. They were not lazy, they could not be forbidden to use version X-1 -- they had an important shipping deadline, which did not permit them to mess around with adapting to version X of XMLS. It would have been entirely reasonable for them to record that they were incompatible with version X in their system definition file, and that would have been A Good Thing, because no one would have been confused by an error message if they had inadvertently updated to XMLS version X.
This example, and related examples (e.g., C code incompatible with the latest GCC, Python code incompatible with Python 3), give an existence proof that your claim (that the client system will never know it's forward-incompatible with a version of one of its libraries) is factually incorrect.
Your argument seems to assume away real world considerations like "I need to ship by Monday and I have three features to add and I don't have time to mess around with code that already works for me, just because a library supplier has decided to change an API," and "I don't want one of my colleagues or customers to be confused if they accidentally install the bleeding edge of this library, which I know is not compatible. So I'll record this fact in my system definition."
Software distributions often ship with multiple versions of software (GCC, JDK, Python, perl, etc) because there are lags between updates in those software systems and downstream systems that depend on them.
For these reasons, upper bounds on library compatibility are entirely reasonable.
Best, r