Drop support for Ruby 2.2 and 2.3 #6945
Comments
|
I would vote for dropping 2.2. The same discussion applies as with dropping support for 2.1 - dropping from the runtime but preserving the parsing support. According to JetBrains stats, 2.2 was used by 20% of developers in 2017 and only 8% in 2018. 2.3 dropped from 58% to 23%. 20% is still a high number. P.S. besides speeding up tests, our codebase could use some 2.3 features ;) |
|
Hmm, that's interesting. Even 8% seems like a lot to me, but I guess we can drop 2.2 if no one objects strongly to this. |
|
I'd be interested in seeing the statistics of Ruby version used for the latest RuboCop gem versions. This might give a better insight into how many people will get upset that they are unable to update RuboCop without updating the Ruby version. In the case when the users of newer versions of RuboCop mostly also prefer newer Ruby versions, I don't see a good reason not to drop support for both 2.2 and 2.3. Unfortunately, RubyGems does not keep track of per-version downloads. What can be measured though is the number of downloads per version of RuboCop gem. It wouldn't mean, of course, that the users of older RuboCop versions are the users of older Ruby versions, but it may be quite likely to be so.
Basing on the early adopter growing rate, and the download trends for older versions we could make a better decision on this. |
|
Kind of an obvious point, but the users who are using old rubies (Perhaps for a legacy app or two out of 10-15 apps at a company), are likely to also have old outdated code. And as such, are unlikely to want to run things like rubocop on it that often. Also given rubocop's popularity as a highly used gem, making it as optimal as possible whilst catering to a large proportion of the userbase I would say is a key point (Yes 8% is large, but 92% is larger..) |
|
Well, let's drop 2.2 and see how things go. I don't really expect much of a fallout from this. |
|
Ruby is new released on every year, and old version becomes EOL around March. I think it is a good time to drop Ruby 2.2 by convention since Ruby 2.3 became EOL. |
|
I've always been a proponent of not supporting old versions. It is really a disservice to enable teams to stay on outdated and unsupported versions. Having popular libraries nudge people along will benefit everyone in the end. Rails does a great job of this (Rails 6 requires Ruby 2.5 or higher.) |
|
Please don't get me wrong, I'm all for dropping support for EOL versions. However, some libraries, e.g. RSpec, do support Ruby 1.8.7 onwards. |
|
Diversity across used RuboCop versions being in use is noticeable.
|
Sure. I opened a PR #7026. |
Fixes rubocop#6945. By convention, a year after Ruby became an EOL, it seems that the old Ruby version support has been dropped. I'm not sure if it's good to drop Ruby 2.3 support, but it's good time to drop Ruby 2.2 support.
Ruby 2.2 and 2.3 support has ended [1], Rubocop support for 2.2 ended and dropping 2.3 as well is close [2]. We also already introduced code that is no more compliant with 2.2. [1]: https://www.ruby-lang.org/en/news/2019/03/31/support-of-ruby-2-3-has-ended/ [2]: rubocop/rubocop#6945
|
I may be late to the party (or too early to a drop support for Ruby 2.4 issue that hasn't yet been created). However I have some general thoughts on dropping Ruby support. Ruby is used for the live API in SketchUp, meaning quite a few people are relying on old Ruby versions. It's not like a rails server where an admin is responsible for keeping things up to date, but up to a sometimes not very tech-savvy end user to update, which includes buying new SketchUp licenses. Also the free version (for non-commercial use) was dropped in 2017 meaning many hobbyists are stuck there, on Ruby 2.2.4. While it's possible to manually exclude Style/SafeNavigation and other cops related to newer Ruby features, along with writing a comment as of why you do it, it would be more straight forward for SketchUp extension developers to just directly target the older Ruby version. If it's not too much problem it would be nice if Rubocop could keep support a bit longer than the official life cycle. Edit: According to the numbers I have over a quarter of SketchUp desktop users are on SketchUp 2017 (Ruby 2.2.4), a fifth in SketchUp 2018 (also Ruby 2.2.4) and a fifth on SketchUp 2019 (Ruby 2.5.5). These number are from April 2018 so the user base has likely shifted a bit, but it still shows how old Ruby versions linger in SketchUp. |
|
@Eneroth3 - You can still use rubocop with ruby 2.2, 2.1 or even lower if you want (Just an older pinned version). What this is saying is going forward to only target newer users of Ruby (or new-ish), with the rubocop restrictions. |
|
@luke-hill I don't really follow. I (as a developer) can update my standalone Ruby interpreter to the newest version at any time. However my users are often stuck in Ruby 2.2, and thus my ruby code needs to be compatible with it. In my case we are not talking about server admins but woodworkers, carpenters, architects etc that would have to pay for a new SketchUp version to update their Ruby interpreter. |
|
That's what |
|
Oh, my bad. I thought this discussion as about dropping Ruby 2.2 support in |
### Summary This PR drops support for Ruby 2.3. It is discussed in rubocop#6945. And this suggestion would mean that RuboCop 1.0 (and pre-release) requires Ruby 2.4 or higher. The following is a plan after this PR. There was a build error report for a dependent jaro_winkler gem. rubocop#5989, rubocop#6754, rubocop#7447, and rubocop#7564. And rubocop#7673 was trying to solve it. After dropping Ruby 2.3, replace jaro_winkler with did_you_mean. did_you_mean is written in Ruby, so the build error due to native extensions no longer occur. That change opens as anther PR. ### Other Information The latest did_you_mean (1.4.0) supports Ruby 2.5 or higher, so it needs to be confirmed old versions it works with Ruby 2.4.
### Summary This PR drops support for Ruby 2.3. It is discussed in #6945. And this suggestion would mean that RuboCop 1.0 (and pre-release) requires Ruby 2.4 or higher. The following is a plan after this PR. There was a build error report for a dependent jaro_winkler gem. #5989, #6754, #7447, and #7564. And #7673 was trying to solve it. After dropping Ruby 2.3, replace jaro_winkler with did_you_mean. did_you_mean is written in Ruby, so the build error due to native extensions no longer occur. That change opens as anther PR. ### Other Information The latest did_you_mean (1.4.0) supports Ruby 2.5 or higher, so it needs to be confirmed old versions it works with Ruby 2.4.
Both of them reached their EOL already and according to our official support policy we don't need to support them anymore.
I don't have a strong take on this, but I'd rather remove them mostly to speed up the test suite. The final decision will also depend on how widely 2.2 and 2.3 are still used in the wild, of course. @rubocop-hq/rubocop-core Any thoughts on this?
The text was updated successfully, but these errors were encountered: