Lock gems

[bethesque]

rake spec task needs certain versions of rspec/rake to work correctly.
Otherwise it may fail with the error: undefined method last_comment for Rake::Application
Without locks to stop major version changes being picked up, the build
will break when backwards incompatible changes are released by any of the gems

[Asmod4n]

This is only for the (automated) tests, right?
If it should be for the howl gem the locks should be set in the .gemspec

[seancribbs]

This looks good to me. Are we not committing Gemfile.lock? If we aren't, I'd encourage adding it.

[bethesque]

The Gemfile.lock is not currently committed. One reason I can see not to is that at least one of us (me) develops on mac, and travis runs on linux, so the dependencies would be different due to this code in the Gemfile:

group :guard do
  gem 'guard-rspec'
  case RbConfig::CONFIG['host_os']
  when /darwin/
    gem 'rb-fsevent'
    # gem 'growl_notify'
    gem 'growl'
  when /linux/
    gem 'rb-inotify'
    gem 'libnotify'
  end
end

[petejohanson]

@seancribbs The conventional wisdom I've always followed (based on http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/) is: Check in Gemfile.lock for applications, don't check in for gems/libraries.

I think better to leave out of the repo, and just lock down versions in the Gemfile.

[bethesque]

@Asmod4n it's just for the development gems. The run time dependencies for the webmachine gem are specified in the gemspec.

[bethesque]

Please note that I've also dropped tests for the unsupported rubies, and added 2.4.1.

[seancribbs]

I just want to thank you all for keeping this project alive. Great work! 😍

[bethesque]

I'm using webmachine for another open source project that's under active development, so it's in my best interests to keep it healthy!