Steve Morris wrote:
> It is then up to me as a developer, with the appropriate notification,
> to determine if the current version of the shared library I am using,
> still contains the apis I am using.

Always assuming you haven't been hit by a bus in the meanwhile, nobody
wants to (or is able to) support your application, but people still need
to build and use it.  End users aren't going to know that sometime
after your death a library supplier changed an API and introduced a
specific version dependency you didn't have before. And they aren't
going to know what to do about it. All they'll know is that the build
scripts you left them don't work anymore.

On the other hand, if you're still alive, you can test with the new
library version and or upgrade your code to use it, and change the
package requirement.

Sort of like the "dead man's switch" on a train. If you're not able to
keep your foot on it, the train stops. The Linux approach requires a
bit more occasional work on the developer's part, but ensures that if
your package becomes orphaned suddenly it will continue to be usable.

> This is how the ole environment in Windows works and is one of the few
> things Microsoft have actually gotten right.
Well, I said "mainframe" before, but I knew this was all founded on
experience in a single-vendor world. The big difference between those
and open-source is that packages don't get orphaned in a single-vendor
world unless the vendor intentionally does that (or goes out of
business). In either of those cases, the customers are screwed.

In Open Source, once you've released something you can't, intentionally
or otherwise, withdraw it. If your app is packaged to use specific
library majors, then it will continue to build and run forever without
modification, as long as those majors are available, whether you're
around or not.