물론 어떤 경우에는 애플리케이션에서 사용하는 특정 의존성만 업데이트하길 원할 수 있습니다. 예를 들어, rails를 3.0.0 최종으로 업데이트한다고 합시다. 중요한 것은 하나의 의존성을 업데이트 해야 하기 때문에 모든 의존성을 업데이트할 필요는 없다는 점입니다. 예제의 의존성은 3개뿐이지만, 이 경우에도 모든 것을 업데이트하는 것은 귀찮은 문제의 원인이 될 수 있습니다.

설명하자면 rails 3.0.0.rc gem은 actionpack 3.0.0.rc gem에 의존하고 있고, 이는 다시 rack ~> 1.2.1에 의존합니다.(>= 1.2.1과 < 1.3.0을 동시에 만족) rack-cache gem은 rack >= 0.4에 의존합니다. rails 3.0.0 최종 gem이 rack ~> 1.2.1에도 의존하고 rails 3.0.0 릴리스 이후에 Rack 팀이 rack 1.2.2를 릴리스했다고 가정해 봅시다.

레일스를 업데이트하기 위해 단순하게 모든 gem을 업데이트한다고 하면, rails 3.0.0과 rack-cache의 요구사항을 모두 만족하는 rack 1.2.2를 얻게될 것입니다. 하지만 rack 1.2.2와 비호환일 수도 있는 rack-cache의 업데이트는 요청한 적이 없습니다.(이유가 무엇이든 간에) 그리고 rack 1.2.1에서 rack 1.2.2로 업데이트 하면 아마 아무것도 망가뜨리지 않을 것입니다만, 훨씬 큰 변경에서는 비슷한 시나리오가 생길 수 있습니다.(더 자세한 논의는 밑의 [1]을 참조하세요.)

이 문제를 피하기 위해, gem을 업데이트할 때 번들러는 다른 gem이 의존하고 있는 gem의 의존성은 업데이트하지 않습니다. 이 예제의 rack-cache가 여전히 rack에 의존하고 있기 때문에 번들러는 rack gem을 업데이트하지 않습니다. 이는 rails의 업데이트가 실수로 rack-cache를 망가트리지 않도록 보증해 줍니다. rails 3.0.0의 의존성인 actionpack 3.0.0이 rack 1.2.1과 호환하기 때문에, 번들러는 그대로 두고, rack-cache는 rack 1.2.2와 비호환임에도 계속 동작하게 됩니다.

원래의 의존성을 rails 3.0.0.rc로 정의했기 때문에, rails 3.0.0으로 업데이트하려 한다면, Gemfile을 gem 'rails', '3.0.0'으로 업데이트하고 다음을 실행하면 됩니다.

$ bundle install

위에서 설명한 것처럼, bundle install 명령은 항상 보수적으로 업데이트를 하고, Gemfile에서 명시적으로 변경하지 않은 gem(또는 그 의존성)을 업데이트하지 않습니다. 이 말은 Gemfile에서 rack-cache를 변경하지 않았다면 번들러는 그것**과 그 의존성**(rack)을 하나의 변경할 수 없는 단위로 취급합니다. rails 3.0.0이 rack-cache와 비호환이라면 번들러는 의존성 스냅숏(Gemfile.lock)과 업데이트된 Gemfile 사이의 충돌을 보고해 줍니다.

Gemfile을 업데이트할 때 시스템이 모든 필요한 의존성을 가지고 있다면, 번들러는 애플리케이션을 시동할 때 Gemfile.lock을 투명하게 업데이트해 줍니다. 예를 들어, Gemfile에 시스템에는 이미 설치되어 있는 mysql을 추가한 경우, bundle install을 실행하지 않고도 애플리케이션을 시동할 수 있고, 번들러는 "마지막으로 성공한" Gemfile.lock 스냅숏 설정을 지속합니다.

이것은 gem을 최소한의 의존성으로 추가하거나 업데이트할 때 유용합니다.(데이터베이스 드라이버, wirble, ruby-debug) 이는 중요한 의존성(rails)이 있는 gem을 업데이트 하거나 gem에 의존성이 많을 경우(rack) 아마도 실패하게 될 것입니다. 투명하게 업데이트가 실패한 경우, 애플리케이션은 기동에 실패하게 되고 bundle install을 실행할 때 번들러는 에러 메시지를 출력할 것입니다.