3 ms·

And not pinning means risk of random API breakage and pinning means you're going to have to manually manage versions anyway. So nothing changes.

• pabs3 5y ago
  That is why you have continuous integration, so you can detect and fix breakage due to API change.
  • junon 5y ago
    CI is only feasible if you make changes to the codebase often. And even then, it's a race condition between you detecting API breakage due to unpinned deps, and a user encountering them. There's nothing wrong with pinning deps and vendoring them.
    • pabs3 5y ago
      You can trigger CI in more ways than just codebase changes; daily/weekly/monthly, when dependencies change versions etc. Then you can know about issues immediately and fix the issues if they are easy to fix or update your dep version ranges if not, then fix the issues at your leisure. Pinning and vendoring just lead to outdated deps with unfixed issues, especially security issues. Vendoring especially was why log4j had such a high impact, because there was no way to just update log4j and then restart affected services. I think we will just have to agree to disagree on this.
      • junon 5y ago
        I guess so. Dependency management isn't a solved problem. You can have all the CI in the world, green keeper, extensive package management toolchains and fancy dedupe/version constraint solvers and still run into pretty catastrophic issues with usability and security. I don't think the log4j example is really relevant here. You can't compare all dependency-related issues to each other.