Provided by: ruby-bundler_1.16.1-1_all bug


       bundle-update - Update your gems to the latest available versions


       bundle     update     *gems     [--group=NAME]    [--source=NAME]    [--local]    [--ruby]
       [--bundler[=VERSION]]      [--full-index]      [--jobs=JOBS]      [--quiet]      [--force]
       [--patch|--minor|--major] [--strict] [--conservative]


       Update  the  gems  specified  (all  gems,  if none are specified), ignoring the previously
       installed gems  specified  in  the  Gemfile.lock.  In  general,  you  should  use  [bundle
       install(1)][bundle-install] to install the same exact gems and versions across machines.

       You would use bundle update to explicitly update the version of a gem.


       --group=<name>, -g=[<name>]
              Only  update the gems in the specified group. For instance, you can update all gems
              in the development group with bundle update --group development. You can also  call
              bundle  update  rails --group test to update the rails gem and all gems in the test
              group, for example.

              The name of a :git or :path source used in the Gemfile(5).  For  instance,  with  a
              :git  source  of,  you  would call bundle update
              --source rails

              Do not attempt to fetch gems remotely and use the gem cache instead.

       --ruby Update the locked version of Ruby to the current version of Ruby.

              Update the locked version of bundler to the invoked bundler version.

              Fall back to using the single-file index of all gems.

       --jobs=[<number>], -j[<number>]
              Specify the number of jobs to run in parallel. The default is 1.

              Retry failed network or git requests for number times.

              Only output warnings and errors.

              Force downloading every gem.

              Prefer updating only to next patch version.

              Prefer updating only to next minor version.

              Prefer updating to next major version (default).

              Do not allow any gem to be updated past latest --patch | --minor | --major.

              Use  bundle  install  conservative  update  behavior  and  do  not   allow   shared
              dependencies to be updated.


       If  you run bundle update with no parameters, bundler will ignore any previously installed
       gems and resolve all dependencies again based on the latest versions of all gems available
       in the sources.

       Consider the following Gemfile(5):

           source ""

           gem "rails", "3.0.0.rc"
           gem "nokogiri"

       When  you run [bundle install(1)][bundle-install] the first time, bundler will resolve all
       of the dependencies, all the way down, and install what you need:

           Fetching gem metadata from
           Resolving dependencies...
           Installing builder 2.1.2
           Installing abstract 1.0.0
           Installing rack 1.2.8
           Using bundler 1.7.6
           Installing rake 10.4.0
           Installing polyglot 0.3.5
           Installing mime-types 1.25.1
           Installing i18n 0.4.2
           Installing mini_portile 0.6.1
           Installing tzinfo 0.3.42
           Installing rack-mount 0.6.14
           Installing rack-test 0.5.7
           Installing treetop 1.4.15
           Installing thor 0.14.6
           Installing activesupport 3.0.0.rc
           Installing erubis 2.6.6
           Installing activemodel 3.0.0.rc
           Installing arel 0.4.0
           Installing mail 2.2.20
           Installing activeresource 3.0.0.rc
           Installing actionpack 3.0.0.rc
           Installing activerecord 3.0.0.rc
           Installing actionmailer 3.0.0.rc
           Installing railties 3.0.0.rc
           Installing rails 3.0.0.rc
           Installing nokogiri 1.6.5

           Bundle complete! 2 Gemfile dependencies, 26 gems total.
           Use `bundle show [gemname]` to see where a bundled gem is installed.

       As you can see, even though you have two gems in the Gemfile(5), your application needs 26
       different  gems  in  order  to  run.  Bundler remembers the exact versions it installed in
       Gemfile.lock. The next time you run [bundle install(1)][bundle-install], bundler skips the
       dependency resolution and installs the same gems as it installed last time.

       After checking in the Gemfile.lock into version control and cloning it on another machine,
       running [bundle install(1)][bundle-install] will still install the gems that you installed
       last  time.  You don´t need to worry that a new release of erubis or mail changes the gems
       you use.

       However, from time to time, you might want to update the gems you are using to the  newest
       versions that still match the gems in your Gemfile(5).

       To  do  this,  run  bundle update, which will ignore the Gemfile.lock, and resolve all the
       dependencies again. Keep in mind that this process can result in a significantly different
       set  of  the  25 gems, based on the requirements of new gems that the gem authors released
       since the last time you ran bundle update.


       Sometimes, you want to update a single gem in the Gemfile(5), and leave the  rest  of  the
       gems that you specified locked to the versions in the Gemfile.lock.

       For instance, in the scenario above, imagine that nokogiri releases version 1.4.4, and you
       want to update it without updating Rails and all of its  dependencies.  To  do  this,  run
       bundle update nokogiri.

       Bundler  will  update  nokogiri and any of its dependencies, but leave alone Rails and its


       Sometimes,  multiple  gems  declared  in  your  Gemfile(5)  are  satisfied  by  the   same
       second-level    dependency.    For    instance,    consider   the   case   of   thin   and

           source ""

           gem "thin"
           gem "rack-perftools-profiler"

       The thin gem depends on rack >= 1.0, while rack-perftools-profiler depends on rack ~> 1.0.
       If you run bundle install, you get:

           Fetching source index for
           Installing daemons (1.1.0)
           Installing eventmachine (0.12.10) with native extensions
           Installing open4 (1.0.1)
           Installing perftools.rb (0.4.7) with native extensions
           Installing rack (1.2.1)
           Installing rack-perftools_profiler (0.0.2)
           Installing thin (1.2.7) with native extensions
           Using bundler (1.0.0.rc.3)

       In  this  case,  the  two  gems have their own set of dependencies, but they share rack in
       common. If you run bundle update thin, bundler will update daemons, eventmachine and rack,
       which  are  dependencies of thin, but not open4 or perftools.rb, which are dependencies of
       rack-perftools_profiler. Note that bundle update thin will update rack  even  though  it´s
       also a dependency of rack-perftools_profiler.

       In  short,  by default, when you update a gem using bundle update, bundler will update all
       dependencies of that gem, including those that are also dependencies of another gem.

       To prevent updating shared dependencies, prior to version 1.14 the  only  option  was  the
       CONSERVATIVE UPDATING behavior in [bundle install(1)][bundle-install]:

       In  this  scenario, updating the thin version manually in the Gemfile(5), and then running
       [bundle install(1)][bundle-install] will only update daemons  and  eventmachine,  but  not
       rack.   For   more   information,   see  the  CONSERVATIVE  UPDATING  section  of  [bundle

       Starting with  1.14,  specifying  the  --conservative  option  will  also  prevent  shared
       dependencies from being updated.


       Version  1.14  introduced  4  patch-level options that will influence how gem versions are
       resolved. One of the following options can be used: --patch, --minor or --major.  --strict
       can be added to further influence resolution.

              Prefer updating only to next patch version.

              Prefer updating only to next minor version.

              Prefer updating to next major version (default).

              Do not allow any gem to be updated past latest --patch | --minor | --major.

       When  Bundler  is  resolving  what versions to use to satisfy declared requirements in the
       Gemfile or in parent gems, it looks up all available versions, filters  out  any  versions
       that  don´t  satisfy  the  requirement,  and  then,  by default, sorts them from newest to
       oldest, considering them in that order.

       Providing one of the patch level options (e.g. --patch) changes  the  sort  order  of  the
       satisfying  versions,  causing  Bundler  to consider the latest --patch or --minor version
       available before other versions. Note that versions outside the stated patch  level  could
       still be resolved to if necessary to find a suitable dependency graph.

       For  example,  if  gem  ´foo´  is  locked at 1.0.2, with no gem requirement defined in the
       Gemfile, and versions 1.0.3, 1.0.4, 1.1.0, 1.1.1, 2.0.0 all exist, the  default  order  of
       preference by default (--major) will be "2.0.0, 1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2".

       If  the  --patch  option  is  used,  the order of preference will change to "1.0.4, 1.0.3,
       1.0.2, 1.1.1, 1.1.0, 2.0.0".

       If the --minor option is used, the order of  preference  will  change  to  "1.1.1,  1.1.0,
       1.0.4, 1.0.3, 1.0.2, 2.0.0".

       Combining the --strict option with any of the patch level options will remove any versions
       beyond the scope of the patch level option, to ensure that no gem is updated that far.

       To continue the previous example, if both --patch  and  --strict  options  are  used,  the
       available  versions for resolution would be "1.0.4, 1.0.3, 1.0.2". If --minor and --strict
       are used, it would be "1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2".

       Gem requirements as defined in the Gemfile will still be the first determining factor  for
       what  versions  are  available. If the gem requirement for foo in the Gemfile is ´~> 1.0´,
       that will accomplish the same thing as providing the --minor and --strict options.


       Given the following gem specifications:

           foo 1.4.3, requires: ~> bar 2.0
           foo 1.4.4, requires: ~> bar 2.0
           foo 1.4.5, requires: ~> bar 2.1
           foo 1.5.0, requires: ~> bar 2.1
           foo 1.5.1, requires: ~> bar 3.0
           bar with versions 2.0.3, 2.0.4, 2.1.0, 2.1.1, 3.0.0


           gem ´foo´


           foo (1.4.3)
             bar (~> 2.0)
           bar (2.0.3)


           #  Command Line                     Result
           1  bundle update --patch            ´foo 1.4.5´, ´bar 2.1.1´
           2  bundle update --patch foo        ´foo 1.4.5´, ´bar 2.1.1´
           3  bundle update --minor            ´foo 1.5.1´, ´bar 3.0.0´
           4  bundle update --minor --strict   ´foo 1.5.0´, ´bar 2.1.1´
           5  bundle update --patch --strict   ´foo 1.4.4´, ´bar 2.0.4´

       In case 1, bar is upgraded to 2.1.1, a minor version increase, because the dependency from
       foo 1.4.5 required it.

       In  case  2, only foo is requested to be unlocked, but bar is also allowed to move because
       it´s not a declared dependency in the Gemfile.

       In case 3, bar goes up a whole major release, because a minor increase  is  preferred  now
       for foo, and when it goes to 1.5.1, it requires 3.0.0 of bar.

       In  case  4,  foo  is  preferred  up  to a minor version, but 1.5.1 won´t work because the
       --strict flag removes bar 3.0.0 from consideration since it´s a major increment.

       In case 5, both foo and bar have any minor or major increments removed from  consideration
       because of the --strict flag, so the most they can move is up to 1.4.4 and 2.0.4.


       In  general,  when  working  with  an application managed with bundler, you should use the
       following workflow:

       ·   After you create your Gemfile(5) for the first time, run

           $ bundle install

       ·   Check the resulting Gemfile.lock into version control

           $ git add Gemfile.lock

       ·   When checking out this repository on another development machine, run

           $ bundle install

       ·   When checking out this repository on a deployment machine, run

           $ bundle install --deployment

       ·   After changing the Gemfile(5) to reflect a new or update dependency, run

           $ bundle install

       ·   Make sure to check the updated Gemfile.lock into version control

           $ git add Gemfile.lock

       ·   If  [bundle  install(1)][bundle-install]  reports  a  conflict,  manually  update  the
           specific gems that you changed in the Gemfile(5)

           $ bundle update rails thin

       ·   If  you  want  to update all the gems to the latest possible versions that still match
           the gems listed in the Gemfile(5), run

           $ bundle update

                                            March 2018                           BUNDLE-UPDATE(1)