3 ms·

Honestly, that's a community problem. If the code is guaranteed to work with the current version of the dependency and packages were built to not break their A

Honestly, that's a community problem. 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

kybernetikos 7y ago
> packages were built to not break their API 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.
0815test 7y ago
> 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 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.
- drchickensalad 7y ago
  I think it's disingenouous to call this a solved problem. Regardless of their appearance, very few projects actually follow this consistently, because it's a lot of work and almost impossible to be sure.

kybernetikos 7y ago

> packages were built to not break their API 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.

0815test 7y ago

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

drchickensalad 7y ago
I think it's disingenouous to call this a solved problem. Regardless of their appearance, very few projects actually follow this consistently, because it's a lot of work and almost impossible to be sure.