Agree with everything you're saying here. What happened in our situation was someone had been working on a feature branch for a few weeks, merged in to the main

Agree with everything you're saying here. What happened in our situation was someone had been working on a feature branch for a few weeks, merged in to the mainline development branch (with failing tests exposing this issue, grr!), and then began the git bisect dance to find the commit that caused the failure. One point I was trying to make in the post (maybe made poorly), was that you probably never want to update the entire gem dependency graph in one fell swoop, just for the hell of it. My read on this is that people tend to do this because they don't fully understand what bundle update is doing when run without any arguments. In the pre-1.0 days, the difference between those commands, at least in my eyes, was extremely ambiguous. So IMHO, updating all gem dependencies to their latest versions, if only for the purpose of "staying current", usually doesn't make practical sense. Sure, there will be bugfixes included in these updates, but unless they were critical security patches, you can probably live without them, unless those bugs are affecting you directly. Even in that case, I would say the solution would be to run bundle update gem-name, only for that gem.