

Don't ever run bundle update - ajsharp
http://optimisdev.com/posts/don-t-ever-run-bundle-update

======
JonnieCache
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
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
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
+1

------
stephencelis
I've found myself in the situation, a few times, where it was necessary to run
`bundle update' to resolve dependency conflicts. You should, of course, always
thoroughly test your application before deploying production code after a
`bundle update', but I'd hardly tell people to not "ever" run the command,
especially if you have git-based dependencies that need to be updated.

~~~
ajsharp
Just to clarify, you can always run bundle update for a specific gem, instead
of for every gem in the Gemfile (this is the behavior if you run the command
without any arguments). Recent versions of bundler (>=1.0) are pretty good
about telling you exactly which gems have dependency conflicts, so it should
be pretty easy to determine which gem to pass to bundle update.

------
grandalf
Does anyone know if there's a command to update your Gemfile to the latest
available version of all gems used?

I'd prefer this b/c it's usually easy to roll back one or two before deploying
if they conflict on my laptop, and having a defined version is preferable to
blindly going with the latest.

~~~
ajsharp
That's what bundle update does, with no other arguments. The other way to use
it is bundle update gem-name, which will only update the gem passed in and
it's dependencies.

~~~
grandalf
It doesn't update the version numbers in the Gemfile, though, does it? IOW
it's only for gems that you haven't locked in a specific version for?

I'd love to be able to ask bundler which of the gems that I _have_ locked in a
version for have a newer version available, so that I can test and decide if I
should update.

~~~
ajsharp
No, it won't update the version numbers in your Gemfile. But to be clear,
let's assume you have the following in your Gemfile:

    
    
        gem "rails", "3.0.0"
        gem "formtastic", ">=1.0.0"
    

Running bundle update (with no arguments) won't update the rails gem to a more
recent version (if it exists), but it _will_ update any of rails'
dependencies, if updates exist.

So, rails has a "specific" dependency on actionpack = 3.0.0, and actionpack
3.0.0 has a dependency on erubis ~> 2.6.6. Let's say (hypothetically) the most
recent published version of erubis is 2.6.7 (which matches the ~> operator),
but the version in your Gemfile.lock is 2.6.6, running bundle update will pull
down that new version of erubis 2.6.7.

Similarly, if a newer version of formtastic were available than the one in
your Gemfile.lock, bundle update would pull this down as well.

~~~
grandalf
In general I have varying levels of confidence in whether I want to stay at
the latest version of a gem or not.

I also don't want to have to constantly check to see if the gems for which
I've fixed the version are the latest... During development I'd be inclined to
keep most gems at the latest version (barring the sort of conflict you
describe), but once the app is in production I'd be likely to be more
cautious, read the changelog, etc., before updating.

It's just that when there are a lot of gems in use, it becomes time consuming
to have to cross-reference the lastest version of each gem whose version I
have fixed with the latest released version. It seems that Bundler is the
natural place for this functionality to live.

------
sjtgraham
You'll need `bundle update foo` if foo has a git source, e.g. `gem 'foo', :git
=> 'git://github.com/johndoe/foo.git'`, and new code committed that you want.

It's not as simple as saying never use it.

~~~
ajsharp
Sorry. Maybe I should've been more clear in the post to say that you should
almost never use bundle update _without arguments_ , which updates the entire
gem dependency graph. Running that command with an argument will only resolve
dependencies (and perform updates) for the gem passed in as an argument to
update command. Apologies for any confusion there :-)

