Support rubocop-performance 1.17.x as well
BrianHawley opened this issue · comments
The spec.add_dependency "rubocop-performance", "~> 1.16.0" restriction causes bundler to choose standard gem versions less than 1.0, if rubocop-performance was already in the Gemfile. Can "~> 1.16" be used instead?
Don't know why dependabot didn't catch this one.
We intentionally track the minor version of rubocop-performance because each minor release brings significant enough changes so as to break the configuration from time to time.
We release standard on a monthly release cadence which will include the latest rubocop-performance update as well.
If you're finding that Bundler is resolving to a <1.0.0 release of Standard, is it by chance 0.0.36.1? If so, then the root cause may be what had previously been an unbounded dependency on RuboCop by the standard gem.
If not, if you could provide a reproducing Gemfile + lockfile, that'd be helpful in figuring out what else is going on
Yup, that was the version bundler picked.
My use case is updating codeclimate's rubocop engine, beta channel, to the latest version of the rubocop gems listed, when those gems are updated.
Recently, someone decided to add references to the standard gem to the rubocop engine, so that people who run standard through rubocop can use the rubocop engine to do so (see codeclimate/codeclimate-rubocop#351 for details). However, since then, standard's gems have been limiting the versions of rubocop's gems. For instance:
- rubocop is 1.51.0 but standard requires
"~> 1.50.2". - rubocop-performance is 1.18.0 but standard-performance requires
"~> 1.16.0".
It would be nice if standard's gems could either be more flexible in their integration, or keep up with the release cadence. I know, it may be unreasonable to ask, especially since standard has their own codeclimate engine.
For context, I think that standardrb/standard#439 may be related to why they added standard to the codeclimate rubocop engine. The codeclimate standard engine hasn't been updated in a while, and (as of that issue) doesn't seem to support loading standard from rubocop, so as to support the rubocop addons that standard doesn't support yet.
Standard releases upstream from RuboCop on a monthly cadence and I don't think we're going to change that, because one of the benefits of using Standard is that we take care to consider and it's time-consuming to cross-reference changelogs, documentation changes, and the (typical) flurry of post-release fixes to new cops. Additionally, because config-file breaking changes are often included in minor releases, we won't further loosen the version specifier either.