-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support rubocop-performance 1.17.x as well #4
Comments
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 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:
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. |
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.
The text was updated successfully, but these errors were encountered: