Closed searls closed 3 months ago
camilopayan
commented
3 months ago 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
commented
3 months ago 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:
">= 0.63", which was completely unbounded and as #340 made very clear, was a pretty boneheaded idea on the part of yours truly ~> 0.67.1, which would select all patch versions of 0.67 (e.g. 0.67.999)"1.48.1", which would select only 1.48.1"~> 1.48.1", which would select all patch versions of 1.48 (e.g. 1.48.999)"~> 1.59.0", which would select all patch versions of 1.59 (e.g. 1.59.999)"~> 1.60", which would select all minor versions of 1 (e.g. 1.999)"~> 1.62", which would select all minor versions of 1 (e.g. 1.999)"~> 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)
I suggest a two-phase solution.
We cut a special release to trap/funnel anyone for whom pubgrub (Bundler's solver) opts for the ~> 1.62 dependency:
1.35.0.1~> 1.60), so it collects everyone affected by either problematic releaseGemfile to a version of standard that's at least v1.35.1 (e.g. gem "standard", ">= 1.35.1")v1.34.0v1.35.0For prior art on how to disable the gem, I put out a similar release v0.0.36.1 that might be helpful.
Per whatever notice above we land on, on that date, someone should yank these from rubygems.org:
v1.35.0v1.34.0camilopayan
commented
3 months ago Okay we're all set, sorry for the inconvenience everyone.
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 updatejust updated my project to rubocop v1.62.0, but the version of standard didn't change: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.35and update? (This is what I did with v0.0.36.1 before said yank.)@camilopayan, I'd appreciate your thoughts here