Bump the required Ruby version to 3.1.0 #50491
Conversation
Until now, Rails only droped compatibility with older rubies on new majors, but I propose to change this policy because it causes us to either keep compatibility with long EOLed rubies or to bump the Rails major more often, and to drop multiple Ruby versions at once when we bump the major. In my opinion it's a bad alignments of incentives. And we'd be much better to just drop support in new minors whenever they go EOL (so 3 years). Also Ruby being an upstream dependency, it's not even a semver violation AFAICT. Since Rails 7.2 isn't planned before a few months, we can already drop Ruby 3.0 as it will be EOL in March.
|
CI is failing because I think you missed the Which is what we use to determine the minimum supported ruby version: This is where we select the images to use: Fixed in byroot#1 (🎉 your first PR)! |
|
Yeah, I agree we should do this. Once upon a time it was more disruptive, because Rubygems/Bundler couldn't account for ruby versions during resolution, and so could settle on a version of a gem that would then not work once installed. But that time is no more. Dropping upstream-unsupported rubies regularly gives users a clearer upgrade path if doing a long catch-up, by better communicating a range of versions that the given Rails version actually spends most of its life running on. No-one should be running Rails 7.1 on now-EOL Ruby 2.7 today, let alone doing so with 7.2 when it's released.
I'm inclined to push one version further forward than that, even, and cut off any version that's in security-only mode at the time of our release (as a general policy, regardless of whether a specific version boundary gives us compelling syntax etc). That's what we've done previously when updating it in majors. But I do also feel less strongly about the need to be that strict if we're revising our minimum more often than once every 2-3 years. (My "that's unreasonable" floor, for comparison, is that any Rails release should support [the now-current patch release of] the version of Ruby that was the latest/current available 12 months earlier.) |
I'm curious if we still need this. It feels like a remnant of having to address the problems with RubyGems/Bundler that Matthew mentioned above. |
I didn't actually look into the purpose of that file, just looking for the most recent ruby version bump last night. Now that you mention it though, that does seem like an accurate assessment: https://github.com/rails/rails/blame/391f2543c96a9b3de4e44f4ea6aeee2f53ad9e5c/railties/bin/rails#L5 edit: Updated byroot#2 to remove the version checker. 🙏 |
Also includes relevant docs, inspired by 6487836
Until now, Rails only droped compatibility with older rubies on new majors, but I propose to change this policy because it causes us to either keep compatibility with long EOLed rubies or to bump the Rails major more often, and to drop multiple Ruby versions at once when we bump the major. In my opinion it's a bad alignments of incentives. And we'd be much better to just drop support in new minors whenever they go EOL (so 3 years). Also Ruby being an upstream dependency, it's not even a semver violation AFAICT. Since Rails 7.2 isn't planned before a few months, we can already drop Ruby 3.0 as it will be EOL in March.
byroot
force-pushed
the
bump-required-ruby
branch
from
89c2f85 to
6ba2fdb
Compare
Yeah, that's my whole point. If we drop more regularly we avoid the need to drop so many at once. Right now I don't see anything in 3.1 that would make our life harder, so I'm not very inclined to drop it. But we can always change our mind before the release if we run into something, it's much easier to drop compatibility than to restore it. |
Remove Ruby version check
|
Alright, since Matthew has no objections, I'll merge now, might as well reduce CI load while we're at it :) |
- Test against 3.3 - Do not test Rails edge against 2.7 (rails/rails#50491)
- Test against 3.3 - Do not test Rails edge against 2.7 (rails/rails#50491)
Also: - Set 7.1 as the default Rails in Gemfile - Do not test Rails edge against Ruby < 3.1 (rails/rails#50491)
* Rails edge requires Ruby version >= 3.1 Ref: rails/rails#50491 * Fix Rubocop offences * Add `mutex_m`a and `base64` to dev dependencies `mutex_m` and `base64` are bundled gem since Ruby 3.4. Rails uses `mutex_m` and `base64` and newer versions add those as dependencies. Ref: rails/rails#48907 But, old Rails aren't supported. So we need to add those gems to run CI.
This commit bumps the minimum Ruby version to 3.1 - Rails 7.2 requires Ruby 3.1 rails/rails#50491 https://guides.rubyonrails.org/7_2_release_notes.html#make-ruby-3-1-the-new-minimum-version - Remove workaround for Ruby 2.7 rsim@8cb2077 ```ruby % ruby -v ruby 3.1.7p261 (2025-03-26 revision 0a3704f218) [arm64-darwin25] % gem -v 3.3.27 % bundler -v Bundler version 2.3.27 % gem update --system Updating rubygems-update Fetching rubygems-update-3.6.9.gem Successfully installed rubygems-update-3.6.9 Parsing documentation for rubygems-update-3.6.9 Installing ri documentation for rubygems-update-3.6.9 Done installing documentation for rubygems-update after 2 seconds Parsing documentation for rubygems-update-3.6.9 Done installing documentation for rubygems-update after 0 seconds Installing RubyGems 3.6.9 Successfully built RubyGem Name: bundler Version: 2.6.9 File: bundler-2.6.9.gem Bundler 2.6.9 installed RubyGems 3.6.9 installed Regenerating binstubs Regenerating plugins Parsing documentation for rubygems-3.6.9 Installing ri documentation for rubygems-3.6.9 ... snip ... RubyGems system software updated ~ % gem -v 3.6.9 ``` - Bump the TargetRubyVersion in .rubocop.yml
4 participants
Until now, Rails only droped compatibility with older rubies on new majors, but I propose to change this policy because it causes us to either keep compatibility with long EOLed rubies or to bump the Rails major more often, and to drop multiple Ruby versions at once when we bump the major.
In my opinion it's a bad alignments of incentives. And we'd be much better to just drop support in new minors whenever they go EOL (so 3 years).
Also Ruby being an upstream dependency, it's not even a semver violation AFAICT.
Since Rails 7.2 isn't planned before a few months, we can already drop Ruby 3.0 as it will be EOL in March.
FYI @matthewd since I think I remember you having opinions about this.