Ultimately this comes down to the elusive and controversial goal
of backwards compatibility.
As a developer of application A, you would like to spend your
time doing three things:
- adding features
- fixing bugs
- if you have done your job well, and there are no features to add or bugs to fix, bask in the glow of having written a long-term stable application that continues to be useful to its users even though you don't have to do a thing to maintain it, such that you can move on to bigger and better things.
And if every last bit of the functionality of application A is
code you wrote yourself, you might have a hope of achieving this.
But to do that you would probably have to reinvent lots of
wheels, and that's no good, either. Another fine software
engineering principle is reuse, or standing on the shoulders of
others. So there is almost certainly at least one resource R that
your application A depends on.
So then the question is, as the maintainer(s) of resource R go
about their work, probably striving for the same three goals as
you — adding features, fixing bugs, trying not to do any extra
work — how much are they supposed to worry about you and
application A?
You'd like them to worry about you a lot: you'd like perfect
backwards compatibility; you'd like them never to make a change
that breaks your application. They probably agree that this
might be nice, but they probably also claim that it's not
realistic: that sometimes, a bugfix or a code refactoring or an
evolving need may force them to make a backwards-incompatible
change. Or there may be "legacy" features which are on their way
through "deprecated" and on the way to "obsolescent", which the
maintainers of resource R are finding it's just way too much work
to continue to support (which is of course why they're
marking those features as "deprecated" or "obsolescent").
The problem is supposed to be ameliorated by a whole separate,
third class of software: dependency managers D which are supposed
to ease the job of managing dependencies between applications like
A and resources like R. Once you've discovered that application
A works with R version 1.x but not R version 2.x, and if you
don't have the time or energy to rewrite A just now, you can
explicitly record this dependency somewhere, and then your users
will get a helpful error message telling them that they're
screwed after upgrading the shared library for R on their machine.
At the end of the day it's either a tradeoff or a stalemate.
The maintainers of R may try, but they're probably not going to
manage (they won't have the time or energy) to achieve as high a level of
backwards compatibility as the maintainers of A might like.
(For any pair {A, R}, of course.) So, once in a while, the
maintainers of A are almost inevitably going to be disappointed,
to discover that they can't just bask in the glow of having a
long-term stable application, because their application has
broken, through no fault of their own.
But you have my absolute sympathy, user16508174. Dependency
management can be a real nightmare (which of course is why the term
dependency hell was coined), and I regularly seethe with
impotent rage against it myself. I wish the maintainers of
resources R worked harder to maintain backwards compatibility,
or better yet, got things right the first time more often so that
they didn't get stuck in these binds in the first place. But my
wishing for it doesn't make it so, and I have little choice but
to resign myself to the occasional (or even pretty regular)
disappointment on this score.
The other thing, as you may have noticed from the tone of the
answers and comments on your question, is that there may be a
certain amount of religious fervor going on here. Not only are
you supposed to accept that your application A is going to be
broken from time to time by forces over which you have no
control, you are not even supposed to complain about it.
This is the way of the world. You are supposed to be glad
that the maintainers of resource R have the freedom to fix bugs
and add features without worrying overmuch about backwards
compatibility. You are supposed to celebrate the extra time
you get to spend learning how to use dependency managers D and
painstakingly recording every last intricate dependency that
application A might have. You should not want to bask in the
glow of long-term stability; that's a confession of some kind of
laziness. You are not supposed to be troubled that, after users
upgrade R on their systems to v2.x in order to satisfy the
dependencies of some other application B, your application A will
be broken, and that those users are about to be pestering you to
spend time upgrading A to use Rv2.x whether you wanted to or not.
This is, again, the way of the world.
Finally, lest this answer be discounted as mere whining, let me say what I would like: I would like the maintainers of any resource R to work harder at achieving backwards compatibility. I know this is asking a lot; I know you're working hard already, and that there aren't enough hours in the day. But the reason I want this is simple: you are, presumably, maintaining resource R as a service to those who use and depend on it. You are doing your work in order to save them work. Presumably, there are more of them than there is of you. So a relatively small amount of work by you is, presumably, leveraged into a huge time savings on behalf of all your users. And making their lives easier by not forcing backwards-incompatible changes upon them is one way you can achieve this.
