I agree with @hunner here. I would recommend a Gemfile.lock if I was shipping an application and it was critical to have precise pinning, but these gems are only used for testing. Even then I might just consider a precise pinning just in my Gemfile :-).

Yes, it may install different gems, but with CI we should be picking up these errors as they occur and fix them. our Gemfile should constrain the version of gems to ensure we don't allow open-ended major version upgrades so the chances of breakage are low.

Also, we often play with the different Gem versions in our Gemfile to allow parameterized builds in travis-ci, and having the lockfile there might interfere with that.

Not to mention the Gemfile.lock maintenance can be a PITA. I can foresee constant Gemfile.lock commits in users patches, and constant requests to 'update our Gemfile.lock' as well, at least this is what I've seen in the past when I've hacked on projects like logstash that used to include Gemfile.lock.

I think honestly one could go either way and suffer pain either way, but yeah, for our modules we've had good mileage not including the Gemfile.lock. Happy to be convinced however :-).