Add restrictive_version_specifiers to Bundler/GemComment

[RobinDaugherty]

The problem I'm trying to solve:

There are multiple reasons one might lock the version of a gem in the Gemfile:

1. When a minimum version of the gem is needed to support the project. (Like ">= 2.0".)
2. When a specific version of the gem has a known bug. (Should be done like "!= 2.4.0".)
3. When a major version of the gem is incompatible with the project. (Usually looks like "< 3.0".)
4. For no reason. Some gems even provide instructions like "add gem 'mygem', '~> 2.3' to your Gemfile".

The last two reasons lead to a project's dependencies falling behind because the bundle update process will not update to 3.0 without manual intervention. This would cause dependencies to continue to fall behind and in some cases even limit other non-locked dependencies because of cross-dependencies.

To combat this, good practice would include a periodic cleanup of Gemfile version specifications that limit updating of gems.

Another good practice is a rule that when a gem has a limiting version specifier like items 3 and 4 above, there's a comment in the Gemfile explaining the reason. This allows the periodic cleanup process to be more effective, since one can determine whether a bug is fixed, or know what kind of breakage or test failure to look for when updating the gem past the version specification.

Currently, the version_specifiers option for this cop checks a gem specification for any version specifier, requiring a gem comment if one exists. This means that a non-limiting version specification like ">= 1.0" without a justification would warrant a complaint.

This new option, limiting_version_specifiers, requires a gem comment only for version specifications that are limiting in nature, but not for other version specifications.

So the following version specifications are permitted without comment:

gem "rubocop", ">= 1.0"
gem "rubocop", "!= 2.3.4"

while the following require an accompanying gem comment:

gem "rubocop", "< 3.0"
gem "rubocop", ">= 1.0", "< 3.0"
gem "rubocop", "~> 2.0"
gem "rubocop", "= 2.3.5"

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

[bbatsov]

I'm fine with the proposed change, but I think you should expand the cop's documentation to account for its rationale.

[bbatsov]

@RobinDaugherty ping :-)

[bbatsov]

I think that's not needed, as it will added automatically once we regen the changelog.

[bbatsov]

The changes look good, but your branch has to be rebased on top of the current master branch due to merge conflicts.

[RobinDaugherty]

✅ I've rebased it.

[bbatsov]

Thanks!