Happy to see this land one day :)

The reason we kept 2.6 is because is comes by default on Mac.

2.7, 3.0 and 3.1 are already deprecated. And if we force people to upgrade, should we just ask them to use at least 3.2?

How do you feel about like updating docs saying 3.2+ preferred, anything else is deprecated. We cut one more release with 2.6 support, then do dropping of 2.7, 3.0, and 3.1.

We'd be following supported Ruby versions at that point and once you bite bullet of 2.6 (pre-installed) - the rest are easier to drop.

Best to do it staged, yes.

We can also prepare the drop of everything below 3.3 by end of March when 3.2 is dropped. That gives people ample time to get ready. We could even make it a warning message displayed in fastlane for those who regularly update fastlane, they would be the ones to be affected the most I guess. Maybe display it last in the console, easy to spot.

The EOL ruby data seems to be here https://github.com/ruby/www.ruby-lang.org/blob/master/_data/branches.yml

Ah good idea! Let me work a PR to emit a message (with an ENV to disable it) for unsupported Rubys and get some team buy-in on that.

PR up for a new feature to emit a message in output if running an unsupported Ruby version - #29840

Ran my issue stats script updated for 2025 til now

> seq 29200 29880 | xargs -L1 -I % gh issue view % | grep '| Ruby                        |' | cut -d '|' -f 3 >> RUBIES   
> ruby -e 'puts File.read("RUBIES").split("\n").map{|l|l.strip.split(".")[0..1].join(".")}.group_by{|l| l}.map{|a| [a[0],a[1].count]}.to_h' 
{"3.2" => 16, "3.3" => 20, "3.1" => 4, "3.4" => 37, "2.7" => 5, "3.0" => 3, "2.6" => 5, "4.0" => 3}

So respectively 5 and 3 issues reported on ruby 2.6 and 2.7 out of 93 issues. Few active reporters whose issues had the ruby version are using ruby 3.0 and 3.1 either. 76 / 93 using 3.2 or later.