Proposed new text for the Caveats in the README:

## Caveats

Quality uses [semantic versioning](http://semver.org/)--any incompatible changes
(including new tools being added) will come out as major number
updates.

New versions of rubocop, however, will often introduce new rules, which
won't be universally adhered to in your code, which in turn may ratchet your
metrics in the wrong direction!  As a result of this we recommend
you lock your Gemfile to a specific minor version of rubocop.

Expect your build to break on major upgrades of this gem,
and minor version upgrades of rubocop.  Because this gem requires
rubocop, rubocop will get updated when you update this gem, unless
you have an explicit constraint on rubocop preventing it (AND YOU SHOULD!).

Things that don't make sense to me:

1. I have to downgrade Rubocop to use Quality?
2. Does Quality actually care which version of Rubocop I am using, from a functional standpoint?
3. I want my build to fail when I upgrade Rubocop. Rubocop should be upgraded intentionally, and every Ruby project should lock it down, as a development dependency. Why should upgrading Rubocop be tied to major releases of Quality, and vice versa?

Yeah, I don't make releases terribly often, so if you want to use this having an old RuboCop is a danger.

Sadly, your ability to lock RuboCop in your local project doesn't affect what's in the Docker image I publish, and I don't want to accidentally get RuboCop updates outside of major version updates in the Docker image.

You'll need to solve that problem before RuboCop can float in the gemspec, as well as figure out how to communicate the RuboCop <-> Docker image version mapping to users.

Another practical matter here is that pronto-rubocop is awaiting a release that will support Rubocop >=1:

prontolabs/pronto-rubocop#47

@apiology It isn't clear to me why there is a mention of docker. I saw this as being a Rubygem, that I would install in my project for code analysis. It seems there is a docker use case that isn't my use case, so perhaps that isn't the only use case?

That's correct; there's a Docker image also published here. Happy to answer questions you have about it; the general goal of it is to provide an alternative way to run this that avoids the pain of installing multiple tools in particular versions, and it's something I use quite a bit in places like CI. There's a CircleCI orb (plugin) here, for instance.

The solution to allow users to update freely in their gem is probably to create a separate constraint in the Dockerfile so that the constraint doesn't need to be put in the gemspec (contributions towards this direction probably welcome).

An update on the above on the Pronto-related constraint - they recently made a release, which may allow for a more aggressive update here in general if they continue on and also loosen the < 1.0 constraint, which didn't make the release.

Also be aware that that I'm looking at moving my use of the functionality of this gem to some other already-generally-supported framework that has drivers for multiple existing tools (e.g. Pronto/Overcommit/etc). Potentially that may include a quality metric violation ratcheting behavior as well - stay tuned!

pronto-rubocop 0.11.1 has been released, which supports RuboCop >= 1.0