Closed causton81 closed 10 years ago
In normal stand alone gem development I would agree but the issue and probably main reason most other vagrant providers dont include the Gemfile.lock is that most of the plugins support multiple versions of vagrant and thus ruby like we do.
If we pushed a Gemfile.lock based on 2.0.0 ruby and then an end user tied to an older Vagrant version tried to use bundler to test on 1.9.3, its likely that because you locked to newer versions of gems that some of those would be incompatible with the older ruby and thus bundling would not work because it would only look at the Gemfile.lock to determine the gem versions to retrieve.
I havent tested the above but did review this with a few folks on IRC and the thoughts were that you would have to manually move in a Gemfile.lock pertinent to both the ruby/vagrant versions being tested so it doesnt provide a major advantage for us to include one and is not really required.
Will merge the other changes but drop the un-ignore of Gemfile.lock until its discussed/tested further (please start an issue thread if you still feel we should still include it).
bundle exec rake
should run with no errors on ruby-2.0.0-p353 which is the same version embedded in vagrant 1.6.5 on Windows.The section "Checking Your Code into Version Control" on http://bundler.io/rationale.html says "After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked." My .lock file may have different versions, so it's probably better for one of the core developers to commit their Gemfile.lock.