bundler 1.16.1 → 1.17.3

data/man/bundle-install.1.txt

@@ -54,55 +54,56 @@ OPTIONS
 
        --force
 	      Force download every gem, even  if  the  required  versions  are
-	      already available locally.
+	      already  available  locally.  --redownload  is  an alias of this
+	      option.
 
        --frozen
-	      Do  not allow the Gemfile.lock to be updated after this install.
-	      Exits non-zero if there are going to  be	changes  to  the  Gem-
+	      Do not allow the Gemfile.lock to be updated after this  install.
+	      Exits  non-zero  if  there  are  going to be changes to the Gem-
 	      file.lock.
 
        --full-index
 	      Bundler will not call Rubygems' API endpoint (default) but down-
 	      load and cache a (currently big) index file of all gems. Perfor-
-	      mance  can  be  improved for large bundles that seldom change by
+	      mance can be improved for large bundles that  seldom  change  by
 	      enabling this option.
 
        --gemfile=<gemfile>
-	      The location of the Gemfile(5) which Bundler  should  use.  This
-	      defaults	to  a  Gemfile(5) in the current working directory. In
+	      The  location  of  the Gemfile(5) which Bundler should use. This
+	      defaults to a Gemfile(5) in the current  working	directory.  In
 	      general, Bundler will assume that the location of the Gemfile(5)
 	      is also the project's root and will try to find Gemfile.lock and
 	      vendor/cache relative to this location.
 
        --jobs=[<number>], -j[<number>]
-	      The maximum number of parallel download and  install  jobs.  The
+	      The  maximum  number  of parallel download and install jobs. The
 	      default is 1.
 
        --local
 	      Do not attempt to connect to rubygems.org. Instead, Bundler will
-	      use the gems already present  in	Rubygems'  cache  or  in  ven-
-	      dor/cache.  Note	that  if  a  appropriate platform-specific gem
+	      use  the	gems  already  present	in  Rubygems' cache or in ven-
+	      dor/cache. Note that  if	a  appropriate	platform-specific  gem
 	      exists on rubygems.org it will not be found.
 
        --no-cache
-	      Do not update the cache in vendor/cache with the	newly  bundled
-	      gems.  This  does not remove any gems in the cache but keeps the
+	      Do  not  update the cache in vendor/cache with the newly bundled
+	      gems. This does not remove any gems in the cache but  keeps  the
 	      newly bundled gems from being cached during the install.
 
        --no-prune
-	      Don't remove stale gems from the	cache  when  the  installation
+	      Don't  remove  stale  gems  from the cache when the installation
 	      finishes.
 
        --path=<path>
-	      The  location to install the specified gems to. This defaults to
-	      Rubygems' setting. Bundler shares this location  with  Rubygems,
-	      gem  install  ... will have gem installed there, too. Therefore,
-	      gems installed without a --path ...  setting  will  show	up  by
+	      The location to install the specified gems to. This defaults  to
+	      Rubygems'  setting.  Bundler shares this location with Rubygems,
+	      gem install ... will have gem installed there,  too.  Therefore,
+	      gems  installed  without	a  --path  ... setting will show up by
 	      calling gem list. Accordingly, gems installed to other locations
 	      will not get listed.
 
        --quiet
-	      Do not  print  progress  information  to	the  standard  output.
+	      Do  not  print  progress	information  to  the  standard output.
 	      Instead, Bundler will exit using a status code ($?).
 
        --retry=[<number>]
@@ -110,34 +111,34 @@ OPTIONS
 
        --shebang=<ruby-executable>
 	      Uses the specified ruby executable (usually ruby) to execute the
-	      scripts created with --binstubs. In addition, if you use	--bin-
-	      stubs  together  with  --shebang jruby these executables will be
+	      scripts  created with --binstubs. In addition, if you use --bin-
+	      stubs together with --shebang jruby these  executables  will  be
 	      changed to execute jruby instead.
 
        --standalone[=<list>]
-	      Makes a bundle that can work without depending  on  Rubygems  or
-	      Bundler  at runtime. A space separated list of groups to install
-	      has to be specified. Bundler creates a  directory  named	bundle
+	      Makes  a	bundle	that can work without depending on Rubygems or
+	      Bundler at runtime. A space separated list of groups to  install
+	      has  to  be  specified. Bundler creates a directory named bundle
 	      and  installs  the  bundle  there.  It  also  generates  a  bun-
-	      dle/bundler/setup.rb file to replace Bundler's own setup in  the
-	      manner  required.  Using this option implicitly sets path, which
+	      dle/bundler/setup.rb  file to replace Bundler's own setup in the
+	      manner required. Using this option implicitly sets  path,  which
 	      is a [remembered option][REMEMBERED OPTIONS].
 
        --system
-	      Installs the gems  specified  in	the  bundle  to  the  system's
-	      Rubygems	location. This overrides any previous configuration of
+	      Installs	the  gems  specified  in  the  bundle  to the system's
+	      Rubygems location. This overrides any previous configuration  of
 	      --path.
 
        --trust-policy=[<policy>]
-	      Apply the Rubygems security policy policy, where policy  is  one
-	      of  HighSecurity, MediumSecurity, LowSecurity, AlmostNoSecurity,
+	      Apply  the  Rubygems security policy policy, where policy is one
+	      of HighSecurity, MediumSecurity, LowSecurity,  AlmostNoSecurity,
 	      or NoSecurity. For more details, please see the Rubygems signing
 	      documentation linked below in SEE ALSO.
 
        --with=<list>
 	      A space-separated list of groups referencing gems to install. If
-	      an optional group is given it is installed. If a group is  given
-	      that  is in the remembered list of groups given to --without, it
+	      an  optional group is given it is installed. If a group is given
+	      that is in the remembered list of groups given to --without,  it
 	      is removed from that list.
 
        --without=<list>
@@ -147,54 +148,54 @@ OPTIONS
 
 DEPLOYMENT MODE
        Bundler's defaults are optimized for development. To switch to defaults
-       optimized  for deployment and for CI, use the --deployment flag. Do not
-       activate deployment mode on development machines, as it will  cause  an
+       optimized for deployment and for CI, use the --deployment flag. Do  not
+       activate  deployment  mode on development machines, as it will cause an
        error when the Gemfile(5) is modified.
 
        1.  A Gemfile.lock is required.
 
 	   To ensure that the same versions of the gems you developed with and
-	   tested with	are  also  used  in  deployments,  a  Gemfile.lock  is
+	   tested  with  are  also  used  in  deployments,  a  Gemfile.lock is
 	   required.
 
-	   This  is  mainly  to  ensure  that  you remember to check your Gem-
+	   This is mainly to ensure that  you  remember  to  check  your  Gem-
 	   file.lock into version control.
 
        2.  The Gemfile.lock must be up to date
 
-	   In development, you can modify your Gemfile(5)  and	re-run	bundle
+	   In  development,  you  can modify your Gemfile(5) and re-run bundle
 	   install to conservatively update your Gemfile.lock snapshot.
 
-	   In  deployment, your Gemfile.lock should be up-to-date with changes
+	   In deployment, your Gemfile.lock should be up-to-date with  changes
 	   made in your Gemfile(5).
 
-       3.  Gems are installed to vendor/bundle not your default  system  loca-
+       3.  Gems  are  installed to vendor/bundle not your default system loca-
 	   tion
 
-	   In  development,  it's  convenient  to  share the gems used in your
-	   application with other applications and other scripts that  run  on
+	   In development, it's convenient to share  the  gems	used  in  your
+	   application	with  other applications and other scripts that run on
 	   the system.
 
-	   In  deployment, isolation is a more important default. In addition,
-	   the user deploying the  application	may  not  have	permission  to
-	   install  gems to the system, or the web server may not have permis-
+	   In deployment, isolation is a more important default. In  addition,
+	   the	user  deploying  the  application  may	not have permission to
+	   install gems to the system, or the web server may not have  permis-
 	   sion to read them.
 
-	   As a result, bundle install --deployment installs gems to the  ven-
-	   dor/bundle  directory  in  the  application. This may be overridden
+	   As  a result, bundle install --deployment installs gems to the ven-
+	   dor/bundle directory in the application.  This  may	be  overridden
 	   using the --path option.
 
 
 
 SUDO USAGE
-       By default, Bundler installs gems to the same location as gem  install.
+       By  default, Bundler installs gems to the same location as gem install.
 
-       In  some cases, that location may not be writable by your Unix user. In
+       In some cases, that location may not be writable by your Unix user.  In
        that case, Bundler will stage everything in a temporary directory, then
-       ask  you  for  your  sudo password in order to copy the gems into their
+       ask you for your sudo password in order to copy	the  gems  into  their
        system location.
 
-       From your  perspective,	this  is  identical  to  installing  the  gems
+       From  your  perspective,  this  is  identical  to  installing  the gems
        directly into the system.
 
        You should never use sudo bundle install. This is because several other
@@ -208,36 +209,36 @@ SUDO USAGE
 
 
 
-       Of these three, the first  two  could  theoretically  be  performed  by
-       chowning  the  resulting  files	to $SUDO_USER. The third, however, can
-       only be performed by invoking the git  command  as  the	current  user.
-       Therefore,  git gems are downloaded and installed into ~/.bundle rather
+       Of  these  three,  the  first  two  could theoretically be performed by
+       chowning the resulting files to $SUDO_USER.  The  third,  however,  can
+       only  be  performed  by	invoking  the git command as the current user.
+       Therefore, git gems are downloaded and installed into ~/.bundle	rather
        than $GEM_HOME or $BUNDLE_PATH.
 
-       As a result, you should run bundle install as  the  current  user,  and
+       As  a  result,  you  should run bundle install as the current user, and
        Bundler will ask for your password if it is needed to put the gems into
        their final location.
 
 INSTALLING GROUPS
-       By default, bundle install will install all gems in all groups in  your
+       By  default, bundle install will install all gems in all groups in your
        Gemfile(5), except those declared for a different platform.
 
-       However,  you  can  explicitly  tell Bundler to skip installing certain
-       groups with the --without option. This option takes  a  space-separated
+       However, you can explicitly tell Bundler  to  skip  installing  certain
+       groups  with  the --without option. This option takes a space-separated
        list of groups.
 
-       While  the --without option will skip installing the gems in the speci-
-       fied groups, it will still download those gems and use them to  resolve
+       While the --without option will skip installing the gems in the	speci-
+       fied  groups, it will still download those gems and use them to resolve
        the dependencies of every gem in your Gemfile(5).
 
        This is so that installing a different set of groups on another machine
-       (such as a production server) will not change  the  gems  and  versions
+       (such  as  a  production  server) will not change the gems and versions
        that you have already developed and tested against.
 
        Bundler offers a rock-solid guarantee that the third-party code you are
        running in development and testing is also the third-party code you are
-       running	in  production. You can choose to exclude some of that code in
-       different environments, but you will never  be  caught  flat-footed  by
+       running in production. You can choose to exclude some of that  code  in
+       different  environments,  but  you  will never be caught flat-footed by
        different versions of third-party code being used in different environ-
        ments.
 
@@ -255,53 +256,63 @@ INSTALLING GROUPS
 
 
 
-       In this case, sinatra depends on any version of Rack  (>=  1.0),  while
+       In  this  case,	sinatra depends on any version of Rack (>= 1.0), while
        rack-perftools-profiler depends on 1.x (~> 1.0).
 
-       When  you  run  bundle  install --without production in development, we
-       look at the dependencies of rack-perftools-profiler as well. That  way,
-       you  do	not spend all your time developing against Rack 2.0, using new
-       APIs unavailable in Rack 1.x, only to have Bundler switch to  Rack  1.2
+       When you run bundle install --without  production  in  development,  we
+       look  at the dependencies of rack-perftools-profiler as well. That way,
+       you do not spend all your time developing against Rack 2.0,  using  new
+       APIs  unavailable  in Rack 1.x, only to have Bundler switch to Rack 1.2
        when the production group is used.
 
-       This  should  not  cause  any  problems	in practice, because we do not
-       attempt to install the gems in the excluded groups, and	only  evaluate
+       This should not cause any problems  in  practice,  because  we  do  not
+       attempt	to  install the gems in the excluded groups, and only evaluate
        as part of the dependency resolution process.
 
-       This  also means that you cannot include different versions of the same
-       gem in different groups, because doing so  would  result  in  different
+       This also means that you cannot include different versions of the  same
+       gem  in	different  groups,  because doing so would result in different
        sets of dependencies used in development and production. Because of the
-       vagaries of the dependency resolution  process,	this  usually  affects
-       more  than the gems you list in your Gemfile(5), and can (surprisingly)
+       vagaries  of  the  dependency  resolution process, this usually affects
+       more than the gems you list in your Gemfile(5), and can	(surprisingly)
        radically change the gems you are using.
 
 THE GEMFILE.LOCK
-       When you run bundle install, Bundler will persist the  full  names  and
-       versions  of all gems that you used (including dependencies of the gems
+       When  you  run  bundle install, Bundler will persist the full names and
+       versions of all gems that you used (including dependencies of the  gems
        specified in the Gemfile(5)) into a file called Gemfile.lock.
 
        Bundler uses this file in all subsequent calls to bundle install, which
        guarantees that you always use the same exact code, even as your appli-
        cation moves across machines.
 
-       Because of the way dependency resolution works, even a seemingly  small
+       Because	of the way dependency resolution works, even a seemingly small
        change (for instance, an update to a point-release of a dependency of a
-       gem in your Gemfile(5)) can result in radically	different  gems  being
+       gem  in	your  Gemfile(5)) can result in radically different gems being
        needed to satisfy all dependencies.
 
-       As  a  result, you SHOULD check your Gemfile.lock into version control.
-       If you do not, every machine that checks out your repository (including
-       your production server) will resolve all dependencies again, which will
-       result in different versions of third-party code being used if  any  of
-       the  gems  in  the  Gemfile(5)  or  any of their dependencies have been
-       updated.
+       As a result, you SHOULD check your Gemfile.lock into  version  control,
+       in both applications and gems. If you do not, every machine that checks
+       out your repository (including your production server) will resolve all
+       dependencies   again,  which  will  result  in  different  versions  of
+       third-party code being used if any of the gems in the Gemfile(5) or any
+       of their dependencies have been updated.
+
+       When  Bundler first shipped, the Gemfile.lock was included in the .git-
+       ignore file included with generated gems. Over time, however, it became
+       clear  that  this  practice forces the pain of broken dependencies onto
+       new  contributors,  while  leaving  existing  contributors  potentially
+       unaware	of the problem. Since bundle install is usually the first step
+       towards a contribution, the pain of broken dependencies would  discour-
+       age  new  contributors  from contributing. As a result, we have revised
+       our guidance for gem authors to now recommend checking in the lock  for
+       gems.
 
 CONSERVATIVE UPDATING
-       When you make a change to the Gemfile(5) and then run  bundle  install,
+       When  you  make a change to the Gemfile(5) and then run bundle install,
        Bundler will update only the gems that you modified.
 
-       In  other  words,  if  a  gem that you did not modify worked before you
-       called bundle install, it will continue to use the exact same  versions
+       In other words, if a gem that you did  not  modify  worked  before  you
+       called  bundle install, it will continue to use the exact same versions
        of all dependencies as it used before the update.
 
        Let's take a look at an example. Here's your original Gemfile(5):
@@ -315,13 +326,13 @@ CONSERVATIVE UPDATING
 
 
 
-       In  this  case, both actionpack and activemerchant depend on activesup-
-       port. The actionpack gem depends on activesupport  2.3.8  and  rack  ~>
-       1.1.0,  while the activemerchant gem depends on activesupport >= 2.3.2,
+       In this case, both actionpack and activemerchant depend	on  activesup-
+       port.  The  actionpack  gem  depends on activesupport 2.3.8 and rack ~>
+       1.1.0, while the activemerchant gem depends on activesupport >=	2.3.2,
        braintree >= 2.0.0, and builder >= 2.0.0.
 
-       When  the  dependencies	are  first  resolved,  Bundler	 will	select
-       activesupport  2.3.8,  which satisfies the requirements of both gems in
+       When   the   dependencies  are  first  resolved,  Bundler  will	select
+       activesupport 2.3.8, which satisfies the requirements of both  gems  in
        your Gemfile(5).
 
        Next, you modify your Gemfile(5) to:
@@ -335,44 +346,44 @@ CONSERVATIVE UPDATING
 
 
 
-       The actionpack 3.0.0.rc gem has	a  number  of  new  dependencies,  and
-       updates	the activesupport dependency to = 3.0.0.rc and the rack depen-
+       The  actionpack	3.0.0.rc  gem  has  a  number of new dependencies, and
+       updates the activesupport dependency to = 3.0.0.rc and the rack	depen-
        dency to ~> 1.2.1.
 
-       When you run bundle install,  Bundler  notices  that  you  changed  the
-       actionpack  gem,  but not the activemerchant gem. It evaluates the gems
+       When  you  run  bundle  install,  Bundler  notices that you changed the
+       actionpack gem, but not the activemerchant gem. It evaluates  the  gems
        currently being used to satisfy its requirements:
 
        activesupport 2.3.8
-	      also used to satisfy a dependency in  activemerchant,  which  is
+	      also  used  to  satisfy a dependency in activemerchant, which is
 	      not being updated
 
        rack ~> 1.1.0
 	      not currently being used to satisfy another dependency
 
-       Because	you did not explicitly ask to update activemerchant, you would
-       not expect it to suddenly stop working after updating actionpack.  How-
-       ever,  satisfying  the new activesupport 3.0.0.rc dependency of action-
+       Because you did not explicitly ask to update activemerchant, you  would
+       not  expect it to suddenly stop working after updating actionpack. How-
+       ever, satisfying the new activesupport 3.0.0.rc dependency  of  action-
        pack requires updating one of its dependencies.
 
-       Even though activemerchant declares a very loose dependency that  theo-
-       retically  matches  activesupport 3.0.0.rc, Bundler treats gems in your
-       Gemfile(5) that have not changed as an atomic unit together with  their
+       Even  though activemerchant declares a very loose dependency that theo-
+       retically matches activesupport 3.0.0.rc, Bundler treats gems  in  your
+       Gemfile(5)  that have not changed as an atomic unit together with their
        dependencies. In this case, the activemerchant dependency is treated as
-       activemerchant 1.7.1 + activesupport  2.3.8,  so  bundle  install  will
+       activemerchant  1.7.1  +  activesupport	2.3.8,	so bundle install will
        report that it cannot update actionpack.
 
        To explicitly update actionpack, including its dependencies which other
-       gems in the Gemfile(5) still depend on, run  bundle  update  actionpack
+       gems  in  the  Gemfile(5) still depend on, run bundle update actionpack
        (see bundle update(1)).
 
-       Summary:  In  general,  after  making  a change to the Gemfile(5) , you
-       should first try to run bundle install, which will  guarantee  that  no
+       Summary: In general, after making a change  to  the  Gemfile(5)	,  you
+       should  first  try  to run bundle install, which will guarantee that no
        other gem in the Gemfile(5) is impacted by the change. If that does not
-       work, run [bundle update(1)][bundle-update].
+       work, run bundle update(1) bundle-update.1.html.
 
 SEE ALSO
-       o   Gem				install 			  docs
+       o   Gem				 install			  docs
 	   http://guides.rubygems.org/rubygems-basics/#installing-gems
 
        o   Rubygems signing docs http://guides.rubygems.org/security/
@@ -382,4 +393,4 @@ SEE ALSO
 
 
 
-				 December 2017		     BUNDLE-INSTALL(1)
+				 December 2018		     BUNDLE-INSTALL(1)

data/man/bundle-install.ronn

@@ -66,7 +66,7 @@ time `bundle install` is run, use `bundle config` (see bundle-config(1)).
 
 * `--force`:
   Force download every gem, even if the required versions are already available
-  locally.
+  locally. `--redownload` is an alias of this option.
 
 * `--frozen`:
   Do not allow the Gemfile.lock to be updated after this install. Exits
@@ -290,12 +290,21 @@ of a dependency of a gem in your Gemfile(5)) can result in radically
 different gems being needed to satisfy all dependencies.
 
 As a result, you `SHOULD` check your `Gemfile.lock` into version
-control. If you do not, every machine that checks out your
-repository (including your production server) will resolve all
+control, in both applications and gems. If you do not, every machine that
+checks out your repository (including your production server) will resolve all
 dependencies again, which will result in different versions of
 third-party code being used if `any` of the gems in the Gemfile(5)
 or any of their dependencies have been updated.
 
+When Bundler first shipped, the `Gemfile.lock` was included in the `.gitignore`
+file included with generated gems.  Over time, however, it became clear that
+this practice forces the pain of broken dependencies onto new contributors,
+while leaving existing contributors potentially unaware of the problem. Since
+`bundle install` is usually the first step towards a contribution, the pain of
+broken dependencies would discourage new contributors from contributing. As a
+result, we have revised our guidance for gem authors to now recommend checking
+in the lock for gems.
+
 ## CONSERVATIVE UPDATING
 
 When you make a change to the Gemfile(5) and then run `bundle install`,
@@ -361,7 +370,7 @@ which other gems in the Gemfile(5) still depend on, run
 `Summary`: In general, after making a change to the Gemfile(5) , you
 should first try to run `bundle install`, which will guarantee that no
 other gem in the Gemfile(5) is impacted by the change. If that
-does not work, run [bundle update(1)][bundle-update].
+does not work, run [bundle update(1)](bundle-update.1.html).
 
 ## SEE ALSO
 

data/man/bundle-list.1

@@ -1,20 +1,50 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "BUNDLE\-LIST" "1" "August 2017" "" ""
+.TH "BUNDLE\-LIST" "1" "December 2018" "" ""
 .
 .SH "NAME"
 \fBbundle\-list\fR \- List all the gems in the bundle
 .
 .SH "SYNOPSIS"
-\fBbundle list\fR [\-\-name\-only]
+\fBbundle list\fR [\-\-name\-only] [\-\-paths] [\-\-without\-group=GROUP] [\-\-only\-group=GROUP]
 .
 .SH "DESCRIPTION"
 Prints a list of all the gems in the bundle including their version\.
 .
+.P
+Example:
+.
+.P
+bundle list \-\-name\-only
+.
+.P
+bundle list \-\-paths
+.
+.P
+bundle list \-\-without\-group test
+.
+.P
+bundle list \-\-only\-group dev
+.
+.P
+bundle list \-\-only\-group dev \-\-paths
+.
 .SH "OPTIONS"
 .
 .TP
 \fB\-\-name\-only\fR
 Print only the name of each gem\.
+.
+.TP
+\fB\-\-paths\fR
+Print the path to each gem in the bundle\.
+.
+.TP
+\fB\-\-without\-group\fR
+Print all gems expect from a group\.
+.
+.TP
+\fB\-\-only\-group\fR
+Print gems from a particular group\.
 

data/man/bundle-list.1.txt

@@ -6,16 +6,38 @@ NAME
        bundle-list - List all the gems in the bundle
 
 SYNOPSIS
-       bundle list [--name-only]
+       bundle	 list	 [--name-only]	  [--paths]    [--without-group=GROUP]
+       [--only-group=GROUP]
 
 DESCRIPTION
        Prints a list of all the gems in the bundle including their version.
 
+       Example:
+
+       bundle list --name-only
+
+       bundle list --paths
+
+       bundle list --without-group test
+
+       bundle list --only-group dev
+
+       bundle list --only-group dev --paths
+
 OPTIONS
        --name-only
 	      Print only the name of each gem.
 
+       --paths
+	      Print the path to each gem in the bundle.
+
+       --without-group
+	      Print all gems expect from a group.
+
+       --only-group
+	      Print gems from a particular group.
+
 
 
 
-				  August 2017			BUNDLE-LIST(1)
+				 December 2018			BUNDLE-LIST(1)

data/man/bundle-list.ronn

@@ -3,13 +3,31 @@ bundle-list(1) -- List all the gems in the bundle
 
 ## SYNOPSIS
 
-`bundle list` [--name-only]
+`bundle list` [--name-only] [--paths] [--without-group=GROUP] [--only-group=GROUP]
 
 ## DESCRIPTION
 
 Prints a list of all the gems in the bundle including their version.
 
+Example:
+
+bundle list --name-only
+
+bundle list --paths
+
+bundle list --without-group test
+
+bundle list --only-group dev
+
+bundle list --only-group dev --paths
+
 ## OPTIONS
 
 * `--name-only`:
   Print only the name of each gem.
+* `--paths`:
+  Print the path to each gem in the bundle.
+* `--without-group`:
+  Print all gems expect from a group.
+* `--only-group`:
+  Print gems from a particular group.

data/man/bundle-lock.1

@@ -1,7 +1,7 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "BUNDLE\-LOCK" "1" "February 2017" "" ""
+.TH "BUNDLE\-LOCK" "1" "November 2018" "" ""
 .
 .SH "NAME"
 \fBbundle\-lock\fR \- Creates / Updates a lockfile without installing
@@ -81,4 +81,4 @@ If you want your bundle to support platforms other than the one you\'re running
 For a full explanation of gem platforms, see \fBgem help platform\fR\.
 .
 .SH "PATCH LEVEL OPTIONS"
-See [bundle update(1)][bundle\-update] for details\.
+See bundle update(1) \fIbundle\-update\.1\.html\fR for details\.

data/man/bundle-lock.1.txt

@@ -86,8 +86,8 @@ SUPPORTING OTHER PLATFORMS
        For a full explanation of gem platforms, see gem help platform.
 
 PATCH LEVEL OPTIONS
-       See [bundle update(1)][bundle-update] for details.
+       See bundle update(1) bundle-update.1.html for details.
 
 
 
-				 February 2017			BUNDLE-LOCK(1)
+				 November 2018			BUNDLE-LOCK(1)

data/man/bundle-lock.ronn

@@ -91,4 +91,4 @@ For a full explanation of gem platforms, see `gem help platform`.
 
 ## PATCH LEVEL OPTIONS
 
-See [bundle update(1)][bundle-update] for details.
+See [bundle update(1)](bundle-update.1.html) for details.

data/man/bundle-open.1

@@ -1,7 +1,7 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "BUNDLE\-OPEN" "1" "February 2017" "" ""
+.TH "BUNDLE\-OPEN" "1" "November 2018" "" ""
 .
 .SH "NAME"
 \fBbundle\-open\fR \- Opens the source directory for a gem in your bundle