Skip to content
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

Decouple minimum TargetRubyVersion from supported runtime platform #10625

Closed
mvz opened this issue May 12, 2022 · 2 comments · Fixed by #10626
Closed

Decouple minimum TargetRubyVersion from supported runtime platform #10625

mvz opened this issue May 12, 2022 · 2 comments · Fixed by #10626
Assignees

Comments

@mvz
Copy link
Contributor

@mvz mvz commented May 12, 2022

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

For many of the gems I maintain, I've set up a combination of the following:

  • A dev dependency on RuboCop with rather liberal version specification (e.g., "~> 1.27"
  • A GitHub Action to run (among others) a RuboCop check, set up to run on pull requests, of course, but also once a month. This Action runs on Ruby 2.7 at the moment.

This combination is intended to catch any new offenses without having to update the gemspec.

However, this plan is no longer working since the Action for some of my projects now fails because latest RubyCop dropped support for Ruby 2.5 as a TargetRubyVersion.

Describe the solution you'd like

Allow TargetRubyVersion 2.5, even when RuboCop itself will only run on Ruby 2.6 and up. This should be possible since Parser supports 2.5 just fine when running on a later Ruby version.

Describe alternatives you've considered

I could use a tighter version specification for RuboCop. However this means churn in the repositiories, and/or potentially not keeping my dependencies up-to-date with the latest versions. Both of these I'd like to avoid, to support my scheme to make maintaining my gems as light-weight as possible.

Additional context

There was a very short but heated discussion about this in the semver repository starting here: semver/semver#716 (comment). I'd like to avoid any discussion of what semver really means and focus on this specific feature.

@bbatsov
Copy link
Collaborator

@bbatsov bbatsov commented May 12, 2022

Hmm, I was under the impression we removed only runtime support for Ruby 2.5, but perhaps I didn't read the PR carefully enough. I'll defer to @koic here, but in principle I agree that we should maintain support for TargetRubyVersion much longer than runtime support.

I also feel that removing support for a TargetRubyVersion is technically speaking a breaking change, which should not happen in a minor release.

koic added a commit to koic/rubocop that referenced this issue May 12, 2022
…2.5`

Fixes rubocop#10625 and reverts part of rubocop#10577.

Only the Ruby version (2.5) to runtime should have been dropped, not code analysis.
This PR the specification to `TargetRubyVersion: 2.5` So, this keeps it compatible
with `TargetRubyVersion` up to 1.28.2.
@koic
Copy link
Member

@koic koic commented May 12, 2022

I'm sorry about it. I've opened #10626 to resolve this issue.

bbatsov pushed a commit that referenced this issue May 12, 2022
Fixes #10625 and reverts part of #10577.

Only the Ruby version (2.5) to runtime should have been dropped, not code analysis.
This PR the specification to `TargetRubyVersion: 2.5` So, this keeps it compatible
with `TargetRubyVersion` up to 1.28.2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants