Gemfile.lock should not be in source control

[RobinDaugherty]

Right now, instead of running on the latest release of Rails 5.1, the CI for this project only runs on the release that is in Gemfile.lock.

When developing a gem, use the gemspec method in your Gemfile to avoid duplication. In general, a gem's Gemfile should contain the Rubygems source and a single gemspec line. Do not check your Gemfile.lock into version control, since it enforces precision that does not exist in the gem command, which is used to install gems in practice. Even if the precision could be enforced, you wouldn't want it, since it would prevent people from using your library with versions of its dependencies that are different from the ones you used to develop the gem.
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

A related improvement that could be made is to run CI builds on multiple releases of Rails and potentially multiple releases of Ruby. Here's an example of this in the better_errors project, but that project had much more complicated requirements, since it has to test both with and without Rails.

If you want, I'd be happy to open a PR to do this.

[ssaunier]

Hi @RobinDaugherty,

That would be great, thanks! I've released a 1.1 with your 2 last PR 🙏