After running the bundle install for the first time, the Gemfile.lock file is generated, which records the specific version number of the gem, and according to the official documentation, running the bundle install will no longer be based on the gemfile, but install the gem according to the lock file. , so that the version installed in the new machine is different from the lock, causing the gem to clutter up. Actual test steps: 1, first run bundle Install,lock file for Sqlite3 (1.3.11-X86-MINGW32) 2, the Gemfile file in the Gem ' sqlite3 ' changed to Gem
' Sqlite3 ',' 1.3.9 ', then run the bundle Install,lock file as Sqlite3 (1.3.9-X86-MINGW32) 2.1, the Gem
' Sqlite3 ',Change ' 1.3.9 ' back to Gem
' Sqlite3 ',
RunBundle Install,lock file is Sqlite3 (1.3.9-X86-MINGW32) 2.2, the Gem
' Sqlite3 ',Change ' 1.3.9 ' back to Gem
' Sqlite3 '
, ' 1.3.11 ',
RunBundle Install,lock file is Sqlite3 (1.3.11-X86-MINGW32) 2.3, the Gem
' Sqlite3 ',Change ' 1.3.9 ' back to Gem
' Sqlite3 '
, ' >=1.3.9 ',
RunThe bundle Install,lock file is Sqlite3 (1.3.9-X86-MINGW32) and is not upgraded to 1.3.112.4, the gem
' Sqlite3 ',Change ' 1.3.9 ' back to Gem
' Sqlite3 '
, ' >=1.3.10 ',
RunBundle Install,lock file for Sqlite3 (1.3.11-X86-MINGW32) Conclusion: 1 It is possible to change a gem in Gemfile without a specific version to a specific version, run the bundle install, modify the lock file, In turn no longer modified, another 2.3 and 2.4 of the situation is very strange, not good explanation, personally think 2.4 should not update the lock file 2 The best practice is to write the specific version in Gemfile, if you need to change, each time with the bundle update Xxgem change a gem version , fully test and then change the version of the second gem; lock files must be included in version management control.
A little bit of adding to bundle install
