* Add Ruby 3.1 to CI
Update Rubocop for recent Rubies
Disable Rubocop run for Rubies before Ruby 2.4
Quote '3.0' in the CI configuration to ensure it loads a 3.0.x Ruby
Set RUBYOPT="--disable_error_highlight" so Ruby 3.1 error matchers pass
* Add CHANGELOG.md entry
* Re-add deleted line from CHANGELOG.md
* Set minimum supported Ruby version to 2.4.
Remove a number of code bits designed to support Rubies below version 2.4
* Bump version. Remove unneeded require from Gemfile. Add require to spec/support file
This is a big step forward in our Rubocop setup. I addressed all of the todos
from the current version of Rubocop that made sense to. The only things that
remain are metrics and one cop that relies on the line length metric to work.
I made some judgment calls on disabling a few cops:
1. The `Layout/IndentHeredoc` cop wants you to either use the squiggly heredoc
from Ruby 2.3 or introduce a library. Since we are a low-level library that
is used as a transitive dependency, we cannot introduce another library as a
dependence, so that option is out. Also, we support Rubies back to 2.0
currently, so using the squiggly heredoc isn't an option. Once we remove
support for Rubies older than 2.3, we can switch to the squiggly heredoc cop.
2. The `Naming/FileName` cop was reporting false positives for a few files in
the repository, so I disabled it on those files.
3. The `Style/DoubleNegation` cop reports lints on a few cases where we use
double negation. Given the very generic nature of Hashie, the double-negation
is the easiest, clearest way to express that we want an item to be a Boolean.
I disabled the cop because we exist in the gray area where this makes sense.
We have a nice integration spec harness, so let's make sure we use it
when we're working on the gem. I'm making the following changes:
* Make `bundle exec rake` run integration specs, except on Travis.
* Silence a warning in the OmniAuth integration spec that has nothing to
do with Hashie.
* Make Guard run integration specs when appropriate. Now, when you run
all tasks you will run integration specs. Also, if you modify an
integration spec, it will run. Lastly, if you modify anything in `lib`
the integration specs will run.
* Keeps the extra Travis build that only runs integration specs. Travis
didn't like the Rake task that included it and there's extra signal by
doing it this way anyway.
Peter Goldstein