search

hotwired / turbo-rails

Use Turbo in your Ruby on Rails app
https://turbo.hotwired.dev
MIT License
2.11k stars 328 forks source link

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

Open dentarg opened 1 month ago

dentarg commented 1 month ago

Happened with https://github.com/hotwired/turbo-rails/commit/5038ed8fcf046f9dbc03b959280a747ee67a08ae#diff-45934cb0c9b4dc0fdd1aa4e780742e07541f16cb60835e1b1330a56d1b0f18f1R9

https://github.com/hotwired/turbo-rails/blob/780ee0da511a3d104683b6852ee00594569109e2/turbo-rails.gemspec#L12

$ 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 commented 1 month ago

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

dhh commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

While https://github.com/hotwired/turbo-rails/commit/5038ed8fcf046f9dbc03b959280a747ee67a08ae#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 ruby@2.6 and rails@6.1 in CI.

There are a variety of gem version incompatibilities and other syntactical incompatibilities. The gem has not been ruby@2.6 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 https://github.com/hotwired/turbo-rails/pull/682's CI failures). The only version of rails that ruby@2.6 is bundle-compatible with is rails@6.1, 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 commented 1 month ago

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