Add Ruby 3.4 support #275
Add Ruby 3.4 support #275
Conversation
|
@abrom Could this be merged and released in rubygems please? Thank you! |
| @@ -16,7 +16,7 @@ Gem::Specification.new do |spec| | |||
| SUMMARY | |||
| spec.homepage = 'https://github.com/Studiosity/grover' | |||
| spec.license = 'MIT' | |||
| spec.required_ruby_version = ['>= 3.0.0', '< 3.4.0'] | |||
| spec.required_ruby_version = ['>= 3.0.0', '< 3.5.0'] | |||
There was a problem hiding this comment.
@abrom Any particular reason to lock Ruby version so tightly in this gem?
It'll be the same problem a few months later when 3.5 is released.
The gem prevents apps using it from upgrading Ruby.
There was a problem hiding this comment.
I agree, it is not a reasonable restriction, except in the school of enterprisey business decisions. Please relegate it to the foibles of the Ruby ecosystem's past!
This is blocking upgrades for me, so I may switch to sourcing from a git fork.
There was a problem hiding this comment.
@abrom Any particular reason to lock Ruby version so tightly in this gem?
It'll be the same problem a few months later when 3.5 is released. The gem prevents apps using it from upgrading Ruby.
Because it hasn't been tested
There was a problem hiding this comment.
I agree, it is not a reasonable restriction, except in the school of enterprisey business decisions. Please relegate it to the foibles of the Ruby ecosystem's past! This is blocking upgrades for me, so I may switch to sourcing from a git fork.
Not reasonable to you, but expected by anyone who needs gems to work with the versions they're indicated as being supported by.
I agree that it is a blocker, no doubt about it. The Ruby versions releasing over what is traditionally a holiday for many, including myself, shouldn't dictate the entire community drop everything to support a pretty extreme minority who need instant version bumps 😉 . If you absolutely need to be using the latest Ruby as soon as it's released is going to result in the need, as you've suggested, for using forks.. that's a given.
There was a problem hiding this comment.
@abrom I get where you're coming from, but most gems don't seem to include a maximum supported Ruby version in their gemfiles from what I can tell, and for the most part this doesn't seem to lead to any problems. Is there a particular concern that grover is likely to break on new versions?
(Grover isn't the only one — I think I noticed nokogiri did too. But they released a new version the same day. I'm absolutely not going to suggest that you should be expected to release new versions on Christmas Day; but I do wonder if removing the upper bound would lead to any actual problems.)
|
Any updates on this? |
You want the gem to support a yet to be released version of the language ? In all likelihood it would work.. yes.. probably. But sorry, I'm not going to open the release versions up for a probably. Each release runs through a CI suite to ensure the gem is going to behave exactly how it is supposed to. How would that work for a yet to be released language? I can assure you that the vitriol I would receive because the gem SAID it supports Ruby X.Y and then for some reason it didn't.. sigh |
|
Thanks @murajun1978 👍 Released in v1.2.2 |
I can only tell you how I do it for the dozens of gems I maintain, and that is: I run the CI against Half a billion downloads later and I haven't recieved any vitriol when a new Ruby release has broken something. I instead often get help fixing the gem, in the form of pull requests. YMMV though. Thanks for releasing, and I'll add a note to my Gemfile to switch to a fork each December. |
|
I'm sure it works fine for you, but I see two big issues.
You just need to look at the number of (deprecated) breakages caused by the 3.4 release whereby a large number of baked in gems were removed. I'm not suggesting that this was the wrong move by the Ruby devs, or that these deprecations couldn't be addressed prior to the next release.. but these were breaking changes none the less.. and ones in a point release. |
Support Ruby 3.4
Fixed #273