The world needs a modern matrix showing the maximum working versions of things in Ruby-land. So I made this.
| ruby | MRI | ARM64& MacOS 12 |
gem | bundler | rubocop | rubocop-lts(*) | rails |
|---|---|---|---|---|---|---|---|
| 1.8.7 | 🙅 | 👋 | 👋👋 | 4.0.x | |||
| 1.9.3 | 🙅 | 2.7.11 | 1.17.3 | 0.41.2 | 1.0, 2.0 | 4.2.x | |
| jruby-1.7.27 | 1.9 | 🌱 | 👆️ | 👆️ | 👆️ | 👆️ | 👆️ |
| 2.0.0 | 🙅 | 👆️ | 👆️ | 0.50.0 | 3.0, 4.0 | 👆️ | |
| 2.1.10 | 🙅 | 👆️ | 👆️ | 0.57.2 | 5.0, 6.0 | 👆️ | |
| 2.2.10 | 🙅 | 👆️ | 👆️ | 0.68.1 | 7.0, 8.0 | 5.2.x | |
| 2.3.8 | 🙅 | 3.0.9 | 2.3.x | 0.81.0 | 9.0, 10.0 | 👆️ | |
| jruby-9.1.17.0 | 2.3 | 🌱 | 👆️ | 👆️ | 👆️ | 👆️ | 👆️ |
| 2.4.10 | 🙅 | 👆️ | 👆️ | 1.12.1 | 11.0, 12.0 | 👆️ | |
| 2.5.9 | 🙅 | 3.3.x | 👆️ | 1.28.2 | 13.0, 14.0 | 6.0.x | |
| jruby-9.2.20.1 | 2.5 | 🌱 | 👆️ | 👆️ | 👆️ | 👆️ | 👆️ |
| 2.6.10 | 🌱 | 👆️ | 👆️ | 1.29.x | 15.0, 16.0 | 6.1.x | |
| jruby-9.3.4.0 | 2.6 | 🌱 | 👆️ | 👆️ | 👆️ | 👆️ | 👆️ |
| 2.7.6 | 🌱 | 👆️ | 👆️ | 👆️ | 17.0, 18.0 | 7.0.0 | |
| 3.0.4 | 🌱 | 👆️ | 👆️ | 👆️ | 19.0, 20.0 | 👆️ | |
| 3.1.2 | 🌱 | 👆️ | 👆️ | 👆️ | 21.0, 22.0 | 7.0.x |
* rubocop-lts has odd versions and even versions.
Rubocop-LTS Odd Versions:
"1.0.0"
"3.0.0"
"5.0.0"
# ... etc
Locked to a single minor version of Ruby, e.g. version 15.0 has a required_ruby_version of ['>= 2.6.0', '< 2.7'], which will install only on 2.6.x versions of Ruby.
Intended for applications and libraries that only lint against a single Ruby version.
Odd versions should be attached to a project's trunk (e.g. the main branch), for long-term stability (ahem, lts 😜) of the style rules.
Rubocop-LTS Even Versions:
"2.0.0"
"4.0.0"
"6.0.0"
# ... etc
Locked to the forward range of Rubies on which the gem can be installed (though rubocop may not execute on all),
e.g. version 16.0 has a required_ruby_version of ['>= 2.6.0', '< 3.2'] will install on any released version
of ruby from 2.6 on.
Intended for applications and libraries that lint against a range of Ruby versions.
Even versions will help projects upgrade to newer Rubies while keeping the same underlying version of Rubocop version, so change can be introduced one step at a time.
Maximum Ruby Version?
Why have this constraint: '< 3.2'?
It's a good question, and for many gems this doesn't make sense, as you expect some trial and error when upgrading a project, and its dependencies, to a new version of Ruby. However, Rubocop LTS is not about trial and error. One purpose of Rubocop LTS is to be a repository of knowledge about what will work. Therefore the maximum version is specified as the latest released stable version of Ruby.
If a future Ruby ends up working with a specific even version of Rubocop LTS, a new patch for that major version will be released which updates required_ruby_version to accommodate. Eventually a new Ruby will be released which does not work, and the latest even major release of Rubocop LTS will always know the last version of Ruby it will work with, because there was no release to enable the next version of Ruby.
Top comments (0)