Constrain (shipped) RuboCop's version

[utkarsh2102]

Right now, we're not specifying the version constraints
on RuboCop that is shipped when a new gem is created.
This can break specs which runs rubocop on a new
skeleton gem as the newer versions of RuboCop are
released.

This commit ensures that the specs don't break by
constraining the RuboCop version.

Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>

---

Tasks:

• Describe the problem / feature
• Write tests
• Write code to solve the problem
• Get code review from coworkers / friends

I will abide by the code of conduct.

[deivid-rodriguez]

@utkarsh2102 I'm not sure this constraint buys us much, since it allows anything under 1.0. I guess we can leave it as it is.

[utkarsh2102]

Hm, since we're also using 0.80.1, I couldn't narrow down the version further.
But sure, if you want to leave it as is, I'm very okay with that, too :)

[deivid-rodriguez]

I was thinking to either:

• Leave it as it is.
• Fully (or at least further) lock it with a conditional on the ruby version, like <%= Gem::Version.new(RUBY_VERSION) >= Gem::Version.new("2.4.a") ? "~> 0.86.0" : "0.80.1" %>

Although on the other hand, rubocop has been recently much less agressive regarding breaking changes on 0.x releases, so the constraint you added is probably just fine, and maybe the best option.

Not really sure, we can revisit in a few days and wait for input from others.

[utkarsh2102]

Sure, we can wait for a while. Maybe a week or so.
But from what I know, there'll be a 1.0.0 release very soon. That'd break something, I think. The minor and patch releases are very unlikely to break something.
But the second option you proposed looks good! 😄

[deivid-rodriguez]

I gave it some more thought, and I think your proposal is the best idea 👍