Is your feature request related to a problem? Please describe.
We were looking to move from running Rubocop locally to super-linter but super-linter uses a version from about 1 year ago (0.74). https://github.com/rubocop-hq/rubocop/releases has 0.85.1 as the latest right now.
Describe the solution you'd like
Upgrade to a more recent version of rubocop, or enable this to be configured by user.
Thanks!
Seems like the specific version was set back in https://github.com/github/super-linter/pull/56 but is not specified why. Also in https://github.com/github/super-linter/pull/101 it was necessary to do some extra fixes to maintain the old version, and in the comments is said to maybe update in the future.
@Hanse00 @admiralAwkbar @zkoppert is there a reason for the specific rubocop version? if not I'm willing to open a PR updating it and removing the weird fix.
@mchusma @GaboFDC We set it to match the internal versions we use on the backend of GitHub, but I do agree, it's getting older...
We need to look at the default rules set in github-rubocop and see what changes need to be made, and how we can make sure this doesn't cause massive listing issues for Ruby when changed.
@admiralAwkbar any update on this?
This is still very weird as rubocop-github:0.13.0 itself has a dependency on rubocop:0.86.0 and that is the whole reason for the weird bug. Maybe we can update it to at aleast 0.86.0?
This is also blocking part of #201 as if we use a package manager, it will fail per the version mismatch
@GaboFDC I need to look as to why we have the internal push back to 0.74 and do some research. Sorry just been low on the priority list. I will try to find some time to look at it over
Don't wanna bother too much, but we are still in time to fix this and get it on #372
Also, my team is blocked as we use some of the newer cops 馃槄
@GaboFDC Thanks for sharing that this is a priority for your team. You can always fork the super linter and make the change then point your report at that until we catch up if needed. Can you confirm the minimum version needed by your team?
@admiralAwkbar in chatting on the #ruby channel, consensus was that for public projects using the default upstream rules would be best. I'd recommend we adopt v0.87.0 and try and stay there until a v1.0.0 is released so we don't get caught up in breaking changes. Thoughts?
Most helpful comment
@mchusma @GaboFDC We set it to match the internal versions we use on the backend of GitHub, but I do agree, it's getting older...
We need to look at the default rules set in
github-rubocopand see what changes need to be made, and how we can make sure this doesn't cause massive listing issues for Ruby when changed.