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

Drop Ruby 2.4 support #9648

Merged
merged 3 commits into from Apr 5, 2021
Merged

Drop Ruby 2.4 support #9648

merged 3 commits into from Apr 5, 2021

Conversation

koic
Copy link
Member

@koic koic commented Mar 31, 2021

This PR drops Ruby 2.4 support. The next release will be the time to drop Ruby 2.4 support.

It includes two workaround separated commits for JRuby.


Before submitting the PR make sure the following are checked:

  • The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
  • Wrote good commit messages.
  • Commit message starts with [Fix #issue-number] (if the related issue exists).
  • Feature branch is up-to-date with master (if not - rebase it).
  • Squashed related commits together.
  • Added tests.
  • Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
  • Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

@marcandre
Copy link
Contributor

Cool. Could you update .mergify.yml also please?

@koic
Copy link
Member Author

koic commented Mar 31, 2021

Ah, I get it! Thank you for your review!

Workaround for jruby/jruby#6642.

This commits prevent the following error when using JRuby 9.2.

```console
% ruby -v
jruby 9.2.17.0 (2.5.8) 2021-03-29 84d363da97 Java HotSpot(TM) 64-Bit
Server VM 25.271-b09 on 1.8.0_271-b09 +jit [darwin-x86_64]

% bundle exec rake documentation_syntax_check
[warn]: Syntax error in
`lib/rubocop/cop/lint/shadowed_exception.rb`:(118,18): syntax error,
unexpected keyword_rescue

[warn]: ParserSyntaxError: syntax error in
`lib/rubocop/cop/lint/shadowed_exception.rb`:(118,18): syntax error,
unexpected keyword_rescue

[warn]: Stack trace:
        /Users/koic/.rbenv/versions/jruby-9.2.17.0/lib/ruby/gems/shared/gems/yard-0.9.26/lib/yard/parser/ruby/ruby_parser.rb:601:in
        `on_parse_error'
        org/jruby/ext/ripper/RubyRipper.java:347:in `parse'
        /Users/koic/.rbenv/versions/jruby-9.2.17.0/lib/ruby/gems/shared/gems/yard-0.9.26/lib/yard/parser/ruby/ruby_parser.rb:56:in
        `parse'
        /Users/koic/.rbenv/versions/jruby-9.2.17.0/lib/ruby/gems/shared/gems/yard-0.9.26/lib/yard/parser/ruby/ruby_parser.rb:17:in
        `parse'
        /Users/koic/.rbenv/versions/jruby-9.2.17.0/lib/ruby/gems/shared/gems/yard-0.9.26/lib/yard/parser/source_parser.rb:442:in
        `parse'
        /Users/koic/.rbenv/versions/jruby-9.2.17.0/lib/ruby/gems/shared/gems/yard-0.9.26/lib/yard/parser/source_parser.rb:46:in
        `block in parse'

Files:         569
Modules:        88 (   13 undocumented)
Classes:       531 (    2 undocumented)
Constants:     892 (  879 undocumented)
Attributes:     31 (    0 undocumented)
Methods:      1186 ( 1060 undocumented)
 28.37% documented
rake aborted!
NoMethodError: undefined method `each' for nil:NilClass
/Users/koic/src/github.com/rubocop/rubocop/Rakefile:105:in `block in
/Users/koic/src/github.com/rubocop/rubocop/Rakefile'
/Users/koic/src/github.com/rubocop/rubocop/lib/rubocop/cop/registry.rb:207:in
`each'
/Users/koic/src/github.com/rubocop/rubocop/Rakefile:96:in `block in
<main>'
/Users/koic/.rbenv/versions/jruby-9.2.17.0/bin/bundle:23:in `<main>'
Tasks: TOP => documentation_syntax_check
(See full trace by running task with --trace)
```
…ing JRuby 9.2

This commits prevent the following build error when using JRuby 9.2.

```console
% ruby -v
jruby 9.2.17.0 (2.5.8) 2021-03-29 84d363da97 Java HotSpot(TM) 64-Bit
Server VM 25.271-b09 on 1.8.0_271-b09 +jit [darwin-x86_64]

% bundle exec rspec ./spec/rubocop/cop/style/parallel_assignment_spec.rb
(snip)

Run options: include {:focus=>true}

All examples were filtered out; ignoring {:focus=>true}

Randomized with seed 34110
...............................................F..F.........F................

Failures:

  1) RuboCop::Cop::Style::ParallelAssignment behaves like allowed allows
  assignment of: obj.attr1, ary[0] = ary[0], obj.attr1
     Failure/Error: expect(actual_annotations.to_s).to eq(source)

       expected: "obj.attr1, ary[0] = ary[0], obj.attr1"
            got: "obj.attr1, ary[0] = ary[0],
            obj.attr1^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do not use
            parallel assignment.\n"

       (compared using ==)

       Diff:
       @@ -1 +1 @@
       -obj.attr1, ary[0] = ary[0], obj.attr1
       +obj.attr1, ary[0] = ary[0],
       obj.attr1^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do not use
       parallel assignment.
(snip)

Finished in 2.29 seconds (files took 4.04 seconds to load)
77 examples, 3 failures

Failed examples:

rspec ./spec/rubocop/cop/style/parallel_assignment_spec.rb[1:42:1] #
RuboCop::Cop::Style::ParallelAssignment behaves like allowed allows
assignment of: obj.attr1, ary[0] = ary[0], obj.attr1
rspec ./spec/rubocop/cop/style/parallel_assignment_spec.rb[1:43:1] #
RuboCop::Cop::Style::ParallelAssignment behaves like allowed allows
assignment of: ary[0], ary[1], ary[2] = ary[1], ary[2], ary[0]
rspec ./spec/rubocop/cop/style/parallel_assignment_spec.rb[1:40:1] #
RuboCop::Cop::Style::ParallelAssignment behaves like allowed allows
assignment of: a[0], a[1] = a[1], a[0]
```

It's supposed to be a JRuby's issue for `array.any?(item)`, it needs to be investigated.
@tas50
Copy link
Contributor

tas50 commented Mar 31, 2021

Other than the general code cleanup is there a driver for dropping Ruby 2.4 support?

@marcandre
Copy link
Contributor

It's been the policy to drop a version of Ruby every year.

Pros are:

  • cleanup
  • we can use more recent features (without needing backports gem 😅 )
  • encourages the community to move forward

Cons are:

  • leaves out the part of the community that has difficulty moving forward

@bbatsov
Copy link
Collaborator

bbatsov commented Mar 31, 2021

There are more details here https://docs.rubocop.org/rubocop/1.12/compatibility.html#support-matrix

Admittedly there's no rush to drop support for Ruby 2.4, but knowing that it has been unsupported for 1 year now and very few people are stuck on it (upgrading to 2.5 is trivial) I don't see much of an issue in dropping it. That being said - one can argue that's also a breaking change now...

@marcandre
Copy link
Contributor

one can argue that's also a breaking change now...

If you are referring to semantic versioning, I don't feel it is. Anytime we bump the requirement for any dependency could be seen as a breaking change...

@bbatsov
Copy link
Collaborator

bbatsov commented Mar 31, 2021

You've convinced me! 😆 I agree with this line of reasoning, but I wonder if all of users subscribe to it. Again - I don't expect much impact from this change, as we're talking about an unsupported version of Ruby. The transition from 1.8 to 1.9 was painful because it required significant code changes in certain cases, but even since it the updates have been so smooth that I doubt many people are stuck on a particular version of Ruby.

@marcandre
Copy link
Contributor

The main reason one could be stuck on a particular version of Ruby is because they use a particular version of Rails... Rails is quite a bit more difficult to upgrade than Ruby.

@Drenmi
Copy link
Collaborator

Drenmi commented Mar 31, 2021

Friends don't let friends stay on ancient versions of Ruby.

It ultimately ends up being a disservice to both the individual and the community, and committing to backwards compatibility wastes time in the past that could be spent getting us into the future. 🙂

@bbatsov
Copy link
Collaborator

bbatsov commented Apr 1, 2021

One additional data point:

image

Twitter wouldn't allow me to add more than 4 answers, so it's hard to say how many people are on Ruby 2.4, but probably half of those 10%.

non_comment_token_line_numbers.none? do |non_comment_line_number|
non_comment_line_number == line_number
end
non_comment_token_line_numbers.none?(line_number)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a cop for this and any? already?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bbatsov
Copy link
Collaborator

bbatsov commented Apr 4, 2021

I'll merge this later next week unless someone violently objects.

@bbatsov bbatsov merged commit 02419b8 into rubocop:master Apr 5, 2021
koic added a commit to koic/rubocop-performance that referenced this pull request Apr 6, 2021
koic added a commit to koic/rubocop-rails that referenced this pull request Apr 6, 2021
koic added a commit to koic/rubocop-minitest that referenced this pull request Apr 6, 2021
@koic koic deleted the drop_ruby_24 branch April 8, 2021 04:57
koic added a commit that referenced this pull request Apr 23, 2021
koic added a commit to koic/rubocop-rails_config that referenced this pull request Apr 23, 2021
RuboCop does not support Ruby 2.4 and rails/rails uses RuboCop 1.13.

- rubocop/rubocop#9648
- rails/rails@bbbc861

And toshimaru#111 requires this PR.
Therefore, this PR drops support for Ruby 2.4 to enable the same cops as rails/rails.
@tagliala
Copy link
Contributor

That being said - one can argue that's also a breaking change now...

Hi, I think this may be considered a breaking change in the scenario I'm experiencing here: Travis CI builds failing for all versions of Ruby except 2.4: https://travis-ci.org/github/DavyJonesLocker/client_side_validations/builds/767962700

Starting from version 1.0, I've locked the RuboCop development dependency to the minor version number, assuming it is safe to upgrade as per SemVer.

Now I could stop supporting Ruby 2.4 on the other gem, but having a major bump in RuboCop would have prevented the build to fail when trying to upgrade an unrelated dependency (puppeteer-core-9.0.0, which is also a major btw, and I thought that it was responsible of the breaking change)

@marcandre
Copy link
Contributor

marcandre commented Apr 24, 2021

There's a big difference between a runtime dependency and a dev/test-only dependency. Which version you decide to support is not quite related to rubocop.

My recommendations:

  1. Remove the add_development_dependency in your gemspec and move them in your Gemfile, possibly conditional on the Ruby version

  2. Have the rubocop run be done only once, for whichever version of Ruby you want, as an independent "build" in your CI. This has the added benefit of making it clear if a failed CI is due to styling or actual test failure. It's also more efficient. We have this setup for the rubocop-ast gem.

tagliala added a commit to DavyJonesLocker/client_side_validations that referenced this pull request Apr 24, 2021
Speed up CI specs by moving RuboCop to an independent build. This will
also prevent issues when RuboCop will drop EOL rubies.

For the moment, this change is enough to keep supporting Ruby 2.4

Ref: rubocop/rubocop#9648
tagliala added a commit to enriclluelles/route_translator that referenced this pull request Apr 25, 2021
tagliala added a commit to enriclluelles/route_translator that referenced this pull request Apr 25, 2021
tagliala added a commit to DavyJonesLocker/client_side_validations-simple_form that referenced this pull request Apr 25, 2021
koic added a commit that referenced this pull request Aug 4, 2021
koic added a commit to koic/guard-rubocop that referenced this pull request Aug 26, 2021
bbatsov pushed a commit to rubocop/guard-rubocop that referenced this pull request Aug 27, 2021
koic added a commit to koic/rubocop-packaging that referenced this pull request Sep 21, 2021
jeremycraney added a commit to jeremycraney/client_side_validations that referenced this pull request Dec 28, 2021
Speed up CI specs by moving RuboCop to an independent build. This will
also prevent issues when RuboCop will drop EOL rubies.

For the moment, this change is enough to keep supporting Ruby 2.4

Ref: rubocop/rubocop#9648
koic added a commit to koic/rubocop that referenced this pull request May 13, 2022
…ersion: 2.4`

Fixes rubocop#10258 and reverts part of rubocop#9648.

Only the Ruby version (2.4) to runtime should have been dropped,
not code analysis.
This PR makes Ruby 2.4 code analysis with `TargetRubyVersion: 2.4`.
So, this keeps it compatible with `TargetRubyVersion` up to
RuboCop 1.12.1 as semver.

It aims to solve essentially the same problem as rubocop#10626.
bbatsov pushed a commit that referenced this pull request May 13, 2022
… 2.4`

Fixes #10258 and reverts part of #9648.

Only the Ruby version (2.4) to runtime should have been dropped,
not code analysis.
This PR makes Ruby 2.4 code analysis with `TargetRubyVersion: 2.4`.
So, this keeps it compatible with `TargetRubyVersion` up to
RuboCop 1.12.1 as semver.

It aims to solve essentially the same problem as #10626.
LeisuPan added a commit to LeisuPan/client_side_validations that referenced this pull request Jul 16, 2022
Speed up CI specs by moving RuboCop to an independent build. This will
also prevent issues when RuboCop will drop EOL rubies.

For the moment, this change is enough to keep supporting Ruby 2.4

Ref: rubocop/rubocop#9648
renawatson68 added a commit to renawatson68/performance-develop-rubyonrails that referenced this pull request Sep 23, 2022
richardstewart0213 added a commit to richardstewart0213/rubyonrails-client_side_validations that referenced this pull request Nov 4, 2022
Speed up CI specs by moving RuboCop to an independent build. This will
also prevent issues when RuboCop will drop EOL rubies.

For the moment, this change is enough to keep supporting Ruby 2.4

Ref: rubocop/rubocop#9648
richardstewart0213 added a commit to richardstewart0213/performance-build-Performance-optimization-analysis- that referenced this pull request Nov 4, 2022
mikejohn857 added a commit to mikejohn857/client_side_validations-ruby that referenced this pull request Nov 25, 2022
Speed up CI specs by moving RuboCop to an independent build. This will
also prevent issues when RuboCop will drop EOL rubies.

For the moment, this change is enough to keep supporting Ruby 2.4

Ref: rubocop/rubocop#9648
azuredevil0818 pushed a commit to azuredevil0818/job-iteration that referenced this pull request Jul 23, 2023
Ruby 2.4 is EOL and Rubocop has accordingly dropped their support.

https://www.ruby-lang.org/en/news/2020/04/05/support-of-ruby-2-4-has-ended/
rubocop/rubocop#9648
https://github.com/rubocop/rubocop/blob/76bc0a0e026b13fccdc7b6bccfd6d082d24a7b52/CHANGELOG.md#1130-2021-04-20

The change to the TargetRubyVersion introduced a violation because of
the redundant `begin`, which has been autocorrected.
MarttiCheng added a commit to MarttiCheng/Rubocop-Performance that referenced this pull request Sep 28, 2023
SerhiiMisiura added a commit to SerhiiMisiura/Rubocop-Performance that referenced this pull request Oct 5, 2023
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 this pull request may close these issues.

None yet

6 participants