A Gem's Gemfile.lock should NOT be in source control. #14

Open
stevenharman opened this Issue Jun 23, 2011 · 2 comments

Projects

None yet

3 participants

@stevenharman

The Gem Development guide says that the Gemfile.lock file "should always be checked into version control." However, this is NOT true for Gems. For Applications, like your Rails apps, Sinatra apps, etc., it is true. The same does not go for Gems.

For clarification, please see Yehuda's guidance on the roles of .gemspec, Gemfile, and Gemfile.lock files: Clarifying the roles of .gemspec and Gemfile

@ms-ati ms-ati added a commit to ms-ati/Values that referenced this issue Apr 6, 2015
@ms-ati ms-ati Remove Gemfile.lock
A gem should not commit Gemfile.lock. In this case,
a stale dependency on json 1.7.5 was breaking my
`bundle install` on ruby 2.2.1, due to the version
incompatibility.

For more information on this, please see:
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
radar/guides#14
TenjinInc/dirt-core#1
cfccf18
@Jwan622

I don't understand his reason. What if my gem depends on say Rails 3 and is not compatible with Rails 4?

@nickmccurdy

Then you should specify a version string for Rails 3 in your Gemfile, while still leaving Gemfile.lock ignored by git. Gemfile.lock is meant to be a full version lock for all dependencies specifically for deploying software. If you depend on certain version ranges of a gem to ensure compatibility, that belongs in Gemfile, not Gemfile.lock.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment