add rails 5.0 5.1 5.2 to ci builds

[nruth]

further to #96

The versions are fed into a ~> in the gemfile, so this should self-update and understand that 5.2 means 5.2.0 to 5.2.x but not 5.3. https://guides.rubygems.org/patterns/#pessimistic-version-constraint

I like not including the patch-level number (or using 0, as previously in this project) because it won't look like they need manually updating.

[valscion]

This looks like a nice approach 👍

Do you think it's necessary to test on all of 2.3, 2.4 and 2.5 rubies? We are now running 4*3 times these tests, and build times are getting larger. Now if we'd get to fixing #41 as well, then there's be quite a lot of CI runs going on.

I'm mainly worried about feedback loops getting longer than what's ideal here. I'm not sure if this is a concern yet, though, so that's why I'm asking for your opinion ☺️

[nruth]

That's a tricky one. I guess the main thing is cover the versions you guys are using internally, and the rest are as a courtesy?

My first thought is to test the lowest supported version + highest supported version. That should cover the two main breaking changes I can think of:

1. APIs used in the gem getting deprecated and removed by new ruby/rails versions. This is covered by testing against a new/modern version.
2. Adding new APIs not supported by the minimum version, e.g. kwargs increased the minimum ruby version, and i can imagine rails 5 having features not available in 4.2. This is covered by testing the minimum versions.

The ruby version is the most painful one with the current travis setup because it runs all of the other combinations again. So sticking to a single ruby version is a good way to cut the combinations. Whatever version that is should probably be set as the minimum supported version, in the sense that it might work on an older version but it's not the maintainers' problem if it doesn't.

Using the lowest official "currently supported Ruby version" seems a safe and inclusive choice. E.g. https://www.ruby-lang.org/en/news/2018/06/20/support-of-ruby-2-2-has-ended/ or sort-of stated on https://www.ruby-lang.org/en/downloads/

For this particular library I would focus on the JR version(s).

So I'd prescribe: ruby 2.3 and rails 4.2 and 5.1. That'd get the build down to 0.9 * 1 ruby * 2 rails = 2 builds, and 4 builds when buliding against JR 0.9 and 0.10

[valscion]

👍. Could we though still test for different Rails minor versions anyway? I'm more worried about potential API changes / deprecations between different Rails minor versions than I am of potential breakage caused by Ruby upgrades.

[valscion]

Yeah this looks good to me! CI should agree as well 😊

[nruth]

I think I misread the ~> docs (I seem to do that every time I look at it) so I've changed it from e.g. 4.2 to 4.2.0.