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:
- 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.
- I fixed XMLS to be robust to this, but at the cost of incompatibility
in the API. I bumped the revision number to X.
System A recorded that it depended on XMLS version X.
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• http://fare.tunes.org Politicians are like rats. What they steal for themselves is minuscule compared to what they destroy getting it.