When you’re really doing Continuous Integration, what strategy should you choose for dealing with dependencies? Should you aggressively pull in changes to that library that the guys in the ivory tower make you use? Or should you wait until there’s a compelling need?
Your hand may be forced by your tooling. If you’re checking in your binary dependencies into your codebase, it may be too painful to get updates frequently. If you’re using a build system built around a dependency manager, you might opt to get the latest, shiniest libraries.
You and your team should make a conscious, strategic choice however: The promiscuous strategy will lead to more integration work, in batches. On the flip side, you’ll never be left wading through updates when there is a compelling need to upgrade through many versions of a library. Proponents of this approach might argue that the batch size on this type of change should be kept small, to minimise risk.
If you’re reluctant to take changes, you’ll experience less integration pain on the project. It’ll be your choice when you update. Proponents of the reluctant approach would argue that they are delivering value, and not wasting development capacity on work that doesn’t deliver business benefits.
Whichever approach you choose: make sure it’s an informed choice.