Ruby version support

[pirj]

I initially started posting this in this ticket, but it's a Rails-related repo, and I would love to apply this to all four repos (rubocop-rspec, rubocop-rspec_rails, rubocop-capybara, rubocop-factory_bot).

Disclaimer upfront: I don't suggest I don't suggest enforcing a 3.2+ somehow in the config/default.yml for the target version.

Instead, I merely propose either:
a) soft-deprecating those versions by removing them from our 27-jobs-long CI matrix.
b) bumping Ruby 3.1/3.2 runtime constraint from 2.7 to 3.2. This has no implication - older rubocop-rspec versions will still run!

I'm not opposed to RuboCop's decision for extended support.

For the context: there are two Ruby version constraints:

1. The minimum version required to run the rubocop command to lint the user's project code. It is also the one we install on CI.
2. The "target" version, the Ruby version used to run the user's project code, and the version that RuboCop should use when parsing the linted code.

Those are different, but not entirely.
On CI it's not a problem to always run the RuboCop CI job with the latest Ruby (like we do now with 3.4!), but setting the TargetRubyVersion to whatever Ruby version the linted project will be run on.
Not entirely 🙈 different because, in practice, if developers run project code locally with some Ruby version X.Y, they also run rubocop command with the same Ruby version. Unless it's some weird docker-like approach where the project code is run with one Ruby version, and all dev tooling with another. But I haven't seen this much.

I wholeheartedly understand that upgrading Ruby versions can be a huge pain, and in my practice using an EOL Ruby versions for a prolongued time, if not forever, is frequent.

I have no objections to supporting old "target" versions.
Even though in our local testing and CI we already seem to use a more modern (2.7) version of Ruby than the parent RuboCop.

To simplify things, RuboCop itself runs the same "runtime" and "target" versions to ensure the promised support for Ruby 2.7 in their latest versions.

But what are the guarantees that if rubocop runs on Ruby 3.4, it will properly parse Ruby 2.7's code? 🤔

RuboCop has Ruby-dependent checks, e.g. this and even this (potentially legacy check as 2.3 is not a supported target Ruby version? Or is it?):

next if target_ruby_version <= 2.3

I could not find such checks or minimum_target_ruby_version anywhere in the four projects we maintain.

To add to this, Rails 8 is (finally!) Ruby 3.2+, and Rails 7.2 is Ruby 3.1+.

Bottom line

But what are the benefits for us to support those older versions?

What are the negative consequences if we, starting from e.g. rubocop-rspec 3.4, stop to run on Ruby < 3.2?
Or even 3.3, since as I recall upgrading from 3.1 -> 3.2 -> 3.3 was easy.

Benefit: burning less GitHub resources.

Bonus

I also propose to remove JRuby from our builds. Not because we don't intend to support it. No, just because the builds are slow, slower than their MRI counterparts.

[bquorning]

If I understand correctly, your primary goal is that we burn less CPU on CI. And secondary, I sense you suggest that “our 27-jobs-long CI matrix” is testing too many versions of Ruby.

I can get behind both of those goals. However:

a) soft-deprecating those versions by removing them from our 27-jobs-long CI matrix.

No longer using Ruby 2.7 on CI will soon lead us to use a Ruby 3.x-only feature. And then we are no longer compatible with Ruby 2.7.

b) bumping Ruby 3.1/3.2 runtime constraint from 2.7 to 3.2. This has no implication - older rubocop-rspec versions will still run!

Then we are no longer compatible with Ruby 2.7.

Both suggestions come down to this: Are we ok with rubocop-rspec no longer being compatible with Ruby 2.7? (And as mentioned in the post, asking people to use a Ruby 3.4 runtime to check their Ruby 2.7 code is not probably not a good idea.)

If we want to keep Ruby 2.7 compatibility, but still run fewer CI jobs, we could run internal_investigation and spec jobs only against the oldest supported Ruby (2.7) and the most recent supported Ruby (3.4). That would would remove 8 jobs (2 for each of 3.0, 3.1, 3.2, and 3.3). I don’t think I have seen CI fail in one of the “middle” Ruby versions but still pass on both the oldest and newest version.