"Whichever version you need" comes with the responsibility of providing security and bugfix upgrades in a timely fashion. Almost all developers fail spectacularly at this, with latencies in the order of months. This is clearly not viable.

As we are all aware, the most secure software is software that doesn't work at all because of library conflicts.

This was my experience as a developer on a SOA team that provided APIs for the rest of the organization (a large regional healthcare system). Even changes that didn't officially break the API could break our customers in ways we didn't anticipate.

When I left that position, we were in the middle of an OpenShift (k8s) deployment, and one of the things motivating the change was the ability to more easily run separate versions of services for different customers if the need arose. Yes, this would put a lot more burden on us as the service provider, but it would also allow us to iterate faster while maintaining stability.

> sometimes the software is not compatible without the developer knowing it

Sure, but this should be considered either a defect or something highlighted by a major version number jump.

Yeah, but who decides if it's a defect? Maybe the defect is subtle and only manifests in rare cases and the upstream rightfully decides that after a risk/payoff analysis, it's not worth fixing it.

Or maybe he agrees and fixes it and it's included in distributions 7 years later.

I've changed 5 jobs in 7 years (because of life circumstances) and I'm not even a job hopper... How is any commercial shop going to plan around 7 year time frames?

Well, within a debian distribution the Debian developer responsible for the downstream package would get the dependency fixed, either themselves or by badgering the maintainer, and use the fixed Debian version. This gives Debian a consistent set of packages that work together. Yes, it's a lot of work and it's why Debian are behind other distributions and don't include Hadoop. But it reduces the unpleasant surprises.

It's effectively part of insisting that it's properly Free software - if you can't maintain your own bugfixed fork, but have to keep going to an external organisation for their version, is it really Free?