Ruby 3.0 syntax introduced from v2.0.8 while gem still claims to support Ruby 2.6.0

[dentarg]

Happened with 5038ed8#diff-45934cb0c9b4dc0fdd1aa4e780742e07541f16cb60835e1b1330a56d1b0f18f1R9

turbo-rails/turbo-rails.gemspec

Line 12 in 780ee0d

s.required_ruby_version = ">= 2.6.0"

$ chruby-exec 2.7 -- ruby -v -e 'def foo() = (@bar)'
ruby 2.7.8p225 (2023-03-30 revision 1f4d455848) [arm64-darwin21]
-e:1: syntax error, unexpected '='
def foo() = (@bar)
-e:1: syntax error, unexpected end-of-input, expecting `end'

$ chruby-exec 3.0.7 -- ruby -v -e 'def foo() = (@bar)'
ruby 3.0.7p220 (2024-04-23 revision 724a071175) [arm64-darwin21]

[dentarg]

What is the intention, bump required_ruby_version? Or was this an accident?

[dhh]

We should bump that minimum version, but also, it shouldn't have happened in a tiny version increment. That was a mistake. cc @seanpdoyle

[seanpdoyle]

This is a test-only change, and can be converted harm-free.

If 2.6 is the target version, we must add 2.6 and 2.7 to the CI matrix. That can be undone in a follow up release.

[seanpdoyle]

While 5038ed8#diff-45934cb0c9b4dc0fdd1aa4e780742e07541f16cb60835e1b1330a56d1b0f18f1R9 is a commit that adds newer 3.0 and 3.1 syntax, reverting those changes alone is not sufficient for executing the test suite for [email protected] and [email protected] in CI.

There are a variety of gem version incompatibilities and other syntactical incompatibilities. The gem has not been [email protected] compatible for some time, and there are likely numerous patch and minor versions released since that time.

Cutting a release to solidify working support for 2.6 would be complicated (evidenced by the #682 CI failures). The only version of rails that [email protected] is bundle-compatible with is [email protected], and that test suite has an importmap-rails compatibility issue. Furthermore, there are several methods throughout the gem that rely on **options merging, and reverting those implementations to use options = {} isn't a mechanical one-to-one replacement.

I think the best course of action is to admit defeat and cut a release that drops support for 2.6 (and maybe even 2.7 and 3.0, since those versions are EOL).

[dhh]

We should probably just cut a major version then that raises the floor to Ruby 3.1, to match Rails 8.