Ability to set a version identifier for NewCops

[connorshea]

Is your feature request related to a problem? Please describe.

I want to enable all the new pending cops released so far, but I don't want to opt into pending cops that will be released in future Rubocop releases.

Describe the solution you'd like

I want to be able to set this in my .rubocop.yml:

AllCops:
  NewCops: '0.87'

And then all pending cops introduced up to (and including) version 0.87 would be enabled, but when 0.88.0 comes out it won't enable any new pending cops by default, and my CI will pass without anyone needing to manually intervene in any way.

The syntax could also be <= 0.87 or something, I'm not picky.

Essentially, I want both of these things:

• Rubocop can be upgraded between minor releases without any manual intervention necessary by me. My CI will just pass and I don't have to care.
• I can go in and bump the version to introduce new pending cops every few weeks/months, whenever I feel like it, without needing to add each and every cop to my .rubocop.yml.

Describe alternatives you've considered

Just enabling all the relevant new cops one-by-one in my .rubocop.yml or just using NewCops: enabled, but neither are really very convenient.

Additional context

I'm not sure if this can be done with existing information in the gem (I think cops already have metadata for when they were introduced?) or if this'd add some new maintenance burden. If it'd add maintenance burden beyond just the initial code to make this work, then it's probably not a big enough deal to bother.

Thanks for the work on Rubocop, I really like the new pending system! :)

[bbatsov]

I think that's a great idea and implementing it would not be hard. We might be able to squeeze this in before the 1.0 release.

[connorshea]

Would or wouldn't be hard? :)

[bbatsov]

wouldn't :-)

[koic]

RuboCop Core, RuboCop Performance, RuboCop Rails, each version is out of sync.
For example, if NewCops: 0.87 is specified, the pending cops of RuboCop Performance 1.x and RuboCop Rails 2.x will be enabled.
A gimmick may be needed to distinguish these.

[pirj]

I want to enable all the new pending cops released so far, but I don't want to opt into pending cops that will be released in future Rubocop releases.

RuboCop warns about the cops introduced with pending status.
Your choice is to either enable, disable them or to keep getting this message.

Imagine you update from 1.0.0 to 1.1.0 and Style/Fashion cop has been introduced.
You enable it.
Then, you update to 1.2.0 that contains a bugfix for Style/Fashion, and also introduces Metrics/Coolness that you don't really want to use just yet.
But eventually, when 2.0 is out, you plan to enable it.
But you keep getting the warning.
Am I getting your problem correctly?

You have two options:

1. Once on 1.1.0, and enabled all pending cops you want, set DisabledByDefault: false. Remove this option when upgrading to 2.0.0.

2. Put Metrics/Coolness with Enabled: false to .rubocop_todo.yml and reconsider this when upgrading to 2.0.0

Will this work for you?

[pirj]

It's possible to make NewCops option per-department. This is a lot of work, however, considering --enable-pending-cops CLI option that would have to accept department arguments. Don't think it's a good solution.

[pirj]

If the workflow fits you, I encourage you to describe it by adding a section to https://github.com/rubocop-hq/rubocop/blob/master/docs/modules/ROOT/pages/versioning.adoc

[bbatsov]

@koic @pirj Thanks for the feedback! I didn't think about the extensions/departments at all. Yeah, when we factor them in that's going to be pretty hard and probably not worth it (e.g. some gem-specific version specifier).

[pirj]

@connorshea Can you please provide your feedback regarding my proposal on how to deal with your use case above. Hope you'll consider that adding a new feature means increased maintenance costs.

[connorshea]

@pirj your proposal makes sense to me. My main goal is just to avoid editing my rubocop config as much as possible, but I acknowledge that the maintenance burden trade-off there falls entirely on the rubocop team. Since it's non-trivial due to the rubocop extensions, I'm fine with abandoning this idea.

Thank you for considering it, though!

[pirj]

@connorshea Thanks for understanding!

@koic @bbatsov Good to close?