3 ms·

If you have a problem where you have auto-updated your whole bundle with `bundle update` and your app is now broken, just remember that you can run `git checkou

If you have a problem where you have auto-updated your whole bundle with `bundle update` and your app is now broken, just remember that you can run `git checkout Gemfile.lock` to revert back to your previous situation. Not really as big a problem as the article makes out. Just make sure you do your `bundle update` and then immediately run your test suite and then immediately commit to your repo, before touching any actual code. Mods to Gemfile.lock should always exist in a commit on their own so that you can easily trace any bugs back to dependency upgrades. If you don't have source control or a test suite, you are fucked. But then you're probably fucked anyway.

ajsharp 16y ago
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.
- JonnieCache 16y ago
  I tend to run `bundle update` all the time for the hell of it during development, when the code is not deployed/being used live anywhere. The codebase is by definition full of bugs anyway because I haven't finished it. May as well be full of the latest bugs, having other people's already fixed bugs in there seems a shame. When I am working on code that is already being used by others and the changes are aimed to be pushed out pretty much as soon as they're 'ready,' I am much more careful and selective about dependency updates.
  - ajsharp 16y ago
    +1

ajsharp 16y ago

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.

JonnieCache 16y ago
I tend to run `bundle update` all the time for the hell of it during development, when the code is not deployed/being used live anywhere. The codebase is by definition full of bugs anyway because I haven't finished it. May as well be full of the latest bugs, having other people's already fixed bugs in there seems a shame. When I am working on code that is already being used by others and the changes are aimed to be pushed out pretty much as soon as they're 'ready,' I am much more careful and selective about dependency updates.
- ajsharp 16y ago
  +1