RuboCop dependency is too loose

[searls]

It looks like when v1.34.0 was released, the version specifier for rubocop was loosened from 3 places (~> 1.59.0) to only 2 (~> 1.60), which is almost definitely not what we want, because RuboCop introduces standard-breaking changes in almost every minor bump that need to be manually triaged.

I caught this because bundle update just updated my project to rubocop v1.62.0, but the version of standard didn't change:

Fetching rubocop 1.62.0 (was 1.61.0)

Based on our mostly-miserable experience dealing with any published version with a too-loose specifier on rubocop, I think this means even if we lock it back down in a subsequent release, users in the future running Bundler will find that its solver will in many cases serve them a very new RuboCop with a soon-to-be-very-old Standard that will definitely be incompatible.

The solution to #340 was to take advantage of the fact nobody was using the ancient versions of Standard in question and we yanked them. Since 1.34.0 is the current release, however, I don't know the right solution.

Perhaps another patch release with no change to the rubocop version specifier that prints a big gnarly message telling them to manually pin to ~> 1.35 and update? (This is what I did with v0.0.36.1 before said yank.)

@camilopayan, I'd appreciate your thoughts here

[camilopayan]

Yea, that's an error on my part, I did not nail the intention on it, though it was to have it looser on the patch, I ended up loosening on the minor version. I don't recall why I ran into this, though I do remember it being an active decision.

I'll look at the options for yanking this and fixing it with a new version of standard.

[searls]

Background

Some more background for arriving to this issue for the first time, here's how Standard has depended on Rubocop since its creation in 2018, because it's changed several times:

• Until v0.0.36 standard depended on rubocop ">= 0.63", which was completely unbounded and as Problems running bundler installed standard and rubocop #340 made very clear, was a pretty boneheaded idea on the part of yours truly
• From v0.0.37 standard depended on rubocop ~> 0.67.1, which would select all patch versions of 0.67 (e.g. 0.67.999)
• At some point, we started pinning rubocop's version exactly, with the last such release being v1.25.2 standard, which depended on rubocop "1.48.1", which would select only 1.48.1
• Starting with v1.25.3, standard depended on rubocop "~> 1.48.1", which would select all patch versions of 1.48 (e.g. 1.48.999)
• The last such release was v1.33.0, which depended on rubocop "~> 1.59.0", which would select all patch versions of 1.59 (e.g. 1.59.999)
• Starting with v1.34.0, standard depended on rubocop "~> 1.60", which would select all minor versions of 1 (e.g. 1.999)
• Which brings us to today's v1.35.0, which depends on rubocop "~> 1.62", which would select all minor versions of 1 (e.g. 1.999)
• UPDATE v1.35.1 was released to lock this back down to the patch-level with specifier "~> 1.62.0"

v1.34.0 and v1.35.0 are problematic, because even if we lock rubocop back down to a patch release of the current minor, Bundler will continue to resolve 1.35.0 for new users that already have a newer rubocop in their bundle until RuboCop 2 is released, which will result in their being served an (eventually) very out-of-date and broken version of Standard. This is basically the same thing we experienced in #340, but at least capped at the minor level (whereas originally, standard's rubocop dep was unbounded)

Proposal

I suggest a two-phase solution.

Phase 1: remediation

We cut a special release to trap/funnel anyone for whom pubgrub (Bundler's solver) opts for the ~> 1.62 dependency:

• Its version number should be 1.35.0.1
• It should retain the exact same RuboCop version selector as v1.34.0's (that is, ~> 1.60), so it collects everyone affected by either problematic release
• It should disable the gem and print a really prominent postinstall message and CLI output warning people that:
  • Explains the issue briefly and points to this thread
  • Offers as a fix that they pin their Gemfile to a version of standard that's at least v1.35.1 (e.g. gem "standard", ">= 1.35.1")
  • Names some future date at which point these two versions will be yanked:
    • v1.34.0
    • v1.35.0

For prior art on how to disable the gem, I put out a similar release v0.0.36.1 that might be helpful.

Phase 2: yanking affected gems

Per whatever notice above we land on, on that date, someone should yank these from rubygems.org:

• v1.35.0
• v1.34.0

[camilopayan]

Okay we're all set, sorry for the inconvenience everyone.