asdf version dependency

Faré fahree at
Thu Mar 17 23:00:35 UTC 2016

> 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.
Emergency patches are sometimes necessary, but they are not meant to
be permanent solutions. It's sometimes necessary to do gross hacks due
to imminent deadlines but that's not a reason to bless them as the
right way to do things.

If your system depends on xmls 1.2 but won't work with xmls 1.3, there
are three real permanent solutions:
a) fix your system and/or the latest xmls so they will work together,
and declare a dependency on the latest (maybe fixed) xmls.
b) fork xmls 1.2 to preserve its API and/or implementation forever,
since it is somehow superior for your purposes.
c) introduce a new system xmls-1.2-compatibility that implements the
missing pieces of the xmls 1.2 API on top of the xmls 1.3 API, if
that's possible and sufficient for your purposes but the maintainer
somehow refuses to do so.

But pretending that there is still a single entity "xmls" when in
actuality there has been a fork in the API with permanent divergent
user communities, is always the wrong thing to do. It's as if ffmpeg
and libav both kept the same name despite being complete forks.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
Politicians are like rats. What they steal for themselves is minuscule
compared to what they destroy getting it.

More information about the asdf-devel mailing list