asdf version dependency

[Robert Goldman]

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