diff options
Diffstat (limited to 'man/bundle-update.1.txt')
| -rw-r--r-- | man/bundle-update.1.txt | 267 |
1 files changed, 133 insertions, 134 deletions
diff --git a/man/bundle-update.1.txt b/man/bundle-update.1.txt index d40b05485a..98df74b09c 100644 --- a/man/bundle-update.1.txt +++ b/man/bundle-update.1.txt @@ -2,85 +2,84 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) -1mNAME0m - 1mbundle-update 22m- Update your gems to the latest available versions +NAME + bundle-update - Update your gems to the latest available versions -1mSYNOPSIS0m - 1mbundle update 4m22m*gems24m [--all] [--group=NAME] [--source=NAME] [--local] +SYNOPSIS + bundle update *gems [--all] [--group=NAME] [--source=NAME] [--local] [--ruby] [--bundler[=VERSION]] [--full-index] [--jobs=JOBS] [--quiet] - [--force] [--patch|--minor|--major] [--strict] [--conservative] + [--patch|--minor|--major] [--redownload] [--strict] [--conservative] -1mDESCRIPTION0m - Update the gems specified (all gems, if 1m--all 22mflag is used), ignoring - the previously installed gems specified in the 1mGemfile.lock22m. In gen- - eral, you should use bundle install(1) 4mbundle-install.1.html24m to install +DESCRIPTION + Update the gems specified (all gems, if --all flag is used), ignoring + the previously installed gems specified in the Gemfile.lock. In gen- + eral, you should use bundle install(1) bundle-install.1.html to install the same exact gems and versions across machines. - You would use 1mbundle update 22mto explicitly update the version of a gem. + You would use bundle update to explicitly update the version of a gem. -1mOPTIONS0m - 1m--all 22mUpdate all gems specified in Gemfile. +OPTIONS + --all Update all gems specified in Gemfile. - 1m--group=<name>22m, 1m-g=[<name>]0m - Only update the gems in the specified group. For instance, you - can update all gems in the development group with 1mbundle update0m - 1m--group development22m. You can also call 1mbundle update rails0m - 1m--group test 22mto update the rails gem and all gems in the test + --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. - 1m--source=<name>0m - The name of a 1m:git 22mor 1m:path 22msource used in the Gemfile(5). For - instance, with a 1m:git 22msource of - 1mhttp://github.com/rails/rails.git22m, you would call 1mbundle update0m - 1m--source rails0m + --source=<name> + The name of a :git or :path source used in the Gemfile(5). For + instance, with a :git source of + http://github.com/rails/rails.git, you would call bundle update + --source rails - 1m--local0m - Do not attempt to fetch gems remotely and use the gem cache in- - stead. + --local + Do not attempt to fetch gems remotely and use the gem cache + instead. - 1m--ruby 22mUpdate the locked version of Ruby to the current version of + --ruby Update the locked version of Ruby to the current version of Ruby. - 1m--bundler0m + --bundler Update the locked version of bundler to the invoked bundler ver- sion. - 1m--full-index0m + --full-index Fall back to using the single-file index of all gems. - 1m--jobs=[<number>]22m, 1m-j[<number>]0m - Specify the number of jobs to run in parallel. The default is 1m122m. + --jobs=[<number>], -j[<number>] + Specify the number of jobs to run in parallel. The default is 1. - 1m--retry=[<number>]0m - Retry failed network or git requests for 4mnumber24m times. + --retry=[<number>] + Retry failed network or git requests for number times. - 1m--quiet0m + --quiet Only output warnings and errors. - 1m--force0m - Force downloading every gem. 1m--redownload 22mis an alias of this - option. + --redownload + Force downloading every gem. - 1m--patch0m + --patch Prefer updating only to next patch version. - 1m--minor0m + --minor Prefer updating only to next minor version. - 1m--major0m + --major Prefer updating to next major version (default). - 1m--strict0m - Do not allow any gem to be updated past latest 1m--patch 22m| 1m--minor0m - | 1m--major22m. + --strict + Do not allow any gem to be updated past latest --patch | --minor + | --major. - 1m--conservative0m + --conservative Use bundle install conservative update behavior and do not allow shared dependencies to be updated. -1mUPDATING ALL GEMS0m - If you run 1mbundle update --all22m, bundler will ignore any previously in- - stalled gems and resolve all dependencies again based on the latest +UPDATING ALL GEMS + If you run bundle update --all, 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): @@ -94,9 +93,9 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) - When you run bundle install(1) 4mbundle-install.1.html24m the first time, - bundler will resolve all of the dependencies, all the way down, and in- - stall what you need: + When you run bundle install(1) bundle-install.1.html the first time, + bundler will resolve all of the dependencies, all the way down, and + install what you need: @@ -134,44 +133,44 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) - 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 1mGemfile.lock22m. The next time you run - bundle install(1) 4mbundle-install.1.html24m, bundler skips the dependency + 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.1.html, bundler skips the dependency resolution and installs the same gems as it installed last time. - After checking in the 1mGemfile.lock 22minto version control and cloning it - on another machine, running bundle install(1) 4mbundle-install.1.html0m - will 4mstill24m install the gems that you installed last time. You don't - need to worry that a new release of 1merubis 22mor 1mmail 22mchanges the gems you + After checking in the Gemfile.lock into version control and cloning it + on another machine, running bundle install(1) bundle-install.1.html + 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 Gem- + 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 Gem- file(5). - To do this, run 1mbundle update --all22m, which will ignore the 1mGem-0m - 1mfile.lock22m, 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 re- - leased since the last time you ran 1mbundle update --all22m. + To do this, run bundle update --all, which will ignore the Gem- + file.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 --all. -1mUPDATING A LIST OF GEMS0m +UPDATING A LIST OF GEMS 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 - 1mGemfile.lock22m. + the rest of the gems that you specified locked to the versions in the + Gemfile.lock. - For instance, in the scenario above, imagine that 1mnokogiri 22mreleases - version 1m1.4.422m, and you want to update it 4mwithout24m updating Rails and all - of its dependencies. To do this, run 1mbundle update nokogiri22m. + 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 1mnokogiri 22mand any of its dependencies, but leave + Bundler will update nokogiri and any of its dependencies, but leave alone Rails and its dependencies. -1mOVERLAPPING DEPENDENCIES0m - Sometimes, multiple gems declared in your Gemfile(5) are satisfied by - the same second-level dependency. For instance, consider the case of - 1mthin 22mand 1mrack-perftools-profiler22m. +OVERLAPPING DEPENDENCIES + Sometimes, multiple gems declared in your Gemfile(5) are satisfied by + the same second-level dependency. For instance, consider the case of + thin and rack-perftools-profiler. @@ -182,8 +181,8 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) - The 1mthin 22mgem depends on 1mrack >= 1.022m, while 1mrack-perftools-profiler 22mde- - pends on 1mrack ~> 1.022m. If you run bundle install, you get: + The thin gem depends on rack >= 1.0, while rack-perftools-profiler + depends on rack ~> 1.0. If you run bundle install, you get: @@ -200,86 +199,86 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) In this case, the two gems have their own set of dependencies, but they - share 1mrack 22min common. If you run 1mbundle update thin22m, bundler will up- - date 1mdaemons22m, 1meventmachine 22mand 1mrack22m, which are dependencies of 1mthin22m, - but not 1mopen4 22mor 1mperftools.rb22m, which are dependencies of - 1mrack-perftools_profiler22m. Note that 1mbundle update thin 22mwill update 1mrack0m - even though it's 4malso24m a dependency of 1mrack-perftools_profiler22m. - - In short, by default, when you update a gem using 1mbundle update22m, - bundler will update all dependencies of that gem, including those that + 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 1mCONSERVATIVE UPDATING 22mbehavior in bundle install(1) 4mbun-0m - 4mdle-install.1.html24m: + option was the CONSERVATIVE UPDATING behavior in bundle install(1) bun- + dle-install.1.html: - In this scenario, updating the 1mthin 22mversion manually in the Gemfile(5), - and then running bundle install(1) 4mbundle-install.1.html24m will only up- - date 1mdaemons 22mand 1meventmachine22m, but not 1mrack22m. For more information, see - the 1mCONSERVATIVE UPDATING 22msection of bundle install(1) 4mbundle-in-0m - 4mstall.1.html24m. + In this scenario, updating the thin version manually in the Gemfile(5), + and then running bundle install(1) bundle-install.1.html will only + update daemons and eventmachine, but not rack. For more information, + see the CONSERVATIVE UPDATING section of bundle install(1) bun- + dle-install.1.html. - Starting with 1.14, specifying the 1m--conservative 22moption will also pre- + Starting with 1.14, specifying the --conservative option will also pre- vent shared dependencies from being updated. -1mPATCH LEVEL OPTIONS0m - Version 1.14 introduced 4 patch-level options that will influence how - gem versions are resolved. One of the following options can be used: - 1m--patch22m, 1m--minor 22mor 1m--major22m. 1m--strict 22mcan be added to further influence +PATCH LEVEL OPTIONS + 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. - 1m--patch0m + --patch Prefer updating only to next patch version. - 1m--minor0m + --minor Prefer updating only to next minor version. - 1m--major0m + --major Prefer updating to next major version (default). - 1m--strict0m - Do not allow any gem to be updated past latest 1m--patch 22m| 1m--minor0m - | 1m--major22m. + --strict + Do not allow any gem to be updated past latest --patch | --minor + | --major. - When Bundler is resolving what versions to use to satisfy declared re- - quirements 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. + When Bundler is resolving what versions to use to satisfy declared + requirements in the Gemfile or in parent gems, it looks up all avail- + able versions, filters out any versions that don't satisfy the require- + ment, and then, by default, sorts them from newest to oldest, consider- + ing them in that order. - Providing one of the patch level options (e.g. 1m--patch22m) changes the - sort order of the satisfying versions, causing Bundler to consider the - latest 1m--patch 22mor 1m--minor 22mversion available before other versions. Note + 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 (1m--major22m) will be + 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 1m--patch 22moption is used, the order of preference will change to + 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 1m--minor 22moption is used, the order of preference will change to + 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 1m--strict 22moption with any of the patch level options will - remove any versions beyond the scope of the patch level option, to en- - sure that no gem is updated that far. + 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 1m--patch 22mand 1m--strict 22moptions + 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 1m--minor 22mand 1m--strict 22mare used, it would be "1.1.1, 1.1.0, + 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 de- - termining factor for what versions are available. If the gem require- - ment for 1mfoo 22min the Gemfile is '~> 1.0', that will accomplish the same - thing as providing the 1m--minor 22mand 1m--strict 22moptions. + Gem requirements as defined in the Gemfile will still be the first + determining factor for what versions are available. If the gem require- + ment for foo in the Gemfile is '~> 1.0', that will accomplish the same + thing as providing the --minor and --strict options. -1mPATCH LEVEL EXAMPLES0m +PATCH LEVEL EXAMPLES Given the following gem specifications: @@ -325,11 +324,11 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) - In case 1, bar is upgraded to 2.1.1, a minor version increase, because + 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 al- - lowed to move because it's not a declared dependency in the Gemfile. + 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 @@ -343,7 +342,7 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) from consideration because of the --strict flag, so the most they can move is up to 1.4.4 and 2.0.4. -1mRECOMMENDED WORKFLOW0m +RECOMMENDED WORKFLOW In general, when working with an application managed with bundler, you should use the following workflow: @@ -351,7 +350,7 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) $ bundle install - o Check the resulting 1mGemfile.lock 22minto version control + o Check the resulting Gemfile.lock into version control $ git add Gemfile.lock @@ -369,11 +368,11 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) $ bundle install - o Make sure to check the updated 1mGemfile.lock 22minto version control + o Make sure to check the updated Gemfile.lock into version control $ git add Gemfile.lock - o If bundle install(1) 4mbundle-install.1.html24m reports a conflict, man- + o If bundle install(1) bundle-install.1.html reports a conflict, man- ually update the specific gems that you changed in the Gemfile(5) $ bundle update rails thin @@ -388,4 +387,4 @@ BUNDLE-UPDATE(1) BUNDLE-UPDATE(1) - January 2019 BUNDLE-UPDATE(1) + April 2019 BUNDLE-UPDATE(1) |