If the code is guaranteed to work with the current version of the dependency and packages were built to not break their API, there would be no problem
I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
That's a lovely sentiment, but it doesn't help much when you've got no consistency between checkouts and builds are failing because of upstream changes that the code you're trying to work with doesn't even know it's using, and to try to fix an issue first requires you to spend days dealing with bitrot.
Here are some principles: 1. only the team working on a component should be able to break the build of that component. 2. Components should not break outside of commits.
The truth is, that your 'API' ends up being every part of your behavior that is relied on by your dependents and their dependents, ad infinitum, and it's almost impossible to make improvements without breaking such an API. Sometimes bugs are part of your de facto API.
It's one thing to say 'people shouldn't depend on these features, look it even says so in the doc', but should and shouldn't are moral judgements, what is and what is not are the distinctions that drive whether your development and release process are fit for purpose.
> I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
Well, there can be debate on the volume of problems on either side, but some other ecosystems attack this with tooling that can automate the process of getting notified that there's an upstream change, rebuilding with the new version, running the automated tests, and making it super easy to accept a commit updating the dependencies if the tests all work.
Semver addresses this. You stick with a specific major version (or minor version for a 0.x release, where "minor" version changes can in fact introduce major breaks), and your dependency tool enforces this. However, it does still warn you if a newer version is available, so that you can start depending on it. (Of course, switching to a newer release is easier said than done if other modules might still depend on the previous one, and your build tool doesn't support the concurrent use of both in the same build!) This is essentially a solved problem.
No-one "managed" the problem. They just sat and watch the community flail around for years.
If the community cannot agree on a simple thing like the package manager, imagine what'll happen if it was in charge of evolving the language
PHP, for all its warts, is 1) very community driven and 2) solved their package management problems via the community (with Composer). Go was not allowed to do that, because everyone knew that any solution had to be blessed by Google.
