make compatible with ruby 3 #174
Conversation
| spec.add_development_dependency "rspec"#, "~> 3.7" | ||
| spec.add_development_dependency "webmock"#, "~> 3.6.2" | ||
| spec.add_development_dependency "rubocop"#, "~> 0.59" | ||
| spec.add_development_dependency 'yajl-ruby'#, '~> 1.4.0' |
There was a problem hiding this comment.
Which of these gemspec changes are necessary? Do you really want all dependencies listed with no version costrains?
There was a problem hiding this comment.
counter question: do you really want to drag along 3 year outdated dependencies although the checks are all green?
There was a problem hiding this comment.
I see, it's a useful experiment and good question for a gem that's not very active. (My question was more "do these belong in same PR" or whether they were debug leftovers committed by mistake.)
However, if you drop constraints entirely, you also allow even older versions! Anything at all if it lets bundler solve the app constraints.
For dev dependencies, maybe that's fine.
For runtime dependencies, IMHO it's safer to at least set >=, and preferably pin major versions to current one (EDIT: I mean each library's last released, not current in this file).
- I never remember what exactly
~>means, love this reference 👀... OK,~> 3.7form means 3.y (y >=7) and is useful;~> 3.6.2form also constrains minor 3.6.z (z >= 2) and is probably unnecessarily strict.
Anyway, I'm not a maintainer here, just watching and pushing my nose occasionally, these are more questions to @kke @jakolehm...
There was a problem hiding this comment.
I haven't touched ruby in a long time. I believe the same applies to many of the other past contributors. If any of you want to take ownership and maintain the gem, I think we will gladly transfer/grant that, @matti ?
There was a problem hiding this comment.
we tried to move the development in this fork: https://github.com/k8s-ruby/k8s-ruby
No description provided.