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.
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.