Software Engineering at Google (2017)

Re:Software Engineering at Google (2017) by pacala on Friday January 04, 2019 @10:53AM (#18824856)

Pinning dependencies is easy, and gets one stuck on Java 1.3 and IE 6. Since the library maintainer doesn't know it broke dependent code, the dependent code will be unlikely to have a smooth upgrade path. It's just a matter of having the luxury of picking up a time to pay the cost of dependency upgrades. Which cost may be high in a world where your dependencies also pin dependencies, likely at different versions.

The underlying assumption it that the project will fold in 2 years anyways, so one may get away with never doing dependency upgrade.

[ Parent | on HN ]

Re:Software Engineering at Google (2017) by alexis_fr on Friday January 04, 2019 @04:10PM (#18827652)

That’s a good point. Do we have any solution from companies who use git/multirepos for their libraries? Is there anyway to compile refactored libraries against existing code?

[ Parent | on HN ]

Re:Software Engineering at Google (2017) by detaro on Friday January 04, 2019 @06:11PM (#18828637)

For various public package managers, there's tools that automatically send e.g. a GitHub PR for an updated dependency file when a dependency updates, which then is tested by CI. I guess something like that could be made for private repos and test versions of packages too, reporting back to the authors of the dependency.

[ Parent | on HN ]