Repository navigation
Additional breaking changes for 6.x #447
Description
Activity
I think it was somewhat reasonable to not support keyword arguments in 2015. Given it's now 2018, and Ruby 2 was obsoleted for almost two years, I don't think there's a good reason to not support them.
It's fine for a HTTP library to be more conservative on Ruby support, but I don't think we should support Ruby versions that Ruby themselves don't support.
We're already 2.2+ so there aren't any issues with older Ruby versions
Oh did we bump the min? I missed that sorry! Then we absolutely should move to keyword arguments.
Totally agree about kwargs!
Fantastic!
Another nice thing to integrate with another breaking change cycle is Socketry, particularly since if we're making breaking changes to the timeout API, there might be some additional ones to consider moving to a Socketry-based timeout system.
Yes, I would love to see #377 merged before 4.0, I think it's a good opportunity for that. I will try to help with porting some socket-related fixes from HTTP.rb to Socketry.
- changed the title
[-]Additional breaking changes for 4.x[/-][+]Additional breaking changes for 5.x[/+]on Oct 14, 2018 - changed the title
[-]Additional breaking changes for 5.x[/-][+]Additional breaking changes for 6.x[/+]on Mar 9, 2026 @zanker commented on Jan 4, 2018:
I think it was somewhat reasonable to not support keyword arguments in 2015. Given it's now 2018, and Ruby 2 was obsoleted for almost two years, I don't think there's a good reason to not support them.
Narrator: It is now 2026 and Ruby 3.0 has been obsoleted for almost two years.
I can work on replacing options with kwargs, since it sounds like everyone is on board with that.
@tarcieri What's the current status of Socketry? I just noticed that it’s archived as of January 2025, but it doesn’t say why. It seems like it would still be useful here and is a generally very popular gem with almost 10 million downloads. Does it need a new maintainer? I’d be happy to being it up-to-date and keep it running, if you’d like.
Reacted by Samuel Williams- added a commit that references this issue
on Mar 19, 2026
#446 will contain breaking changes. Since we're bumping major versions against at a
x.0.0release, perhaps it's worth considering if there are any additional breaking changes we want to make before a new major version release.I'll bring up the elephant in the room again: keyword arguments, namely converting the existing option hashes in the API into keyword arguments.
My one sentence argument why: keyword arguments automatically check the validity of all keys passed and raise exceptions automatically for e.g. incorrect argument names, improving correctness. They also simplify passing defaults (no need to use the
opts = { ... }.merge(options)pattern, and can therefore significantly reduce allocations (going from twoHashallocations to, depending on the underlying implementation, potentially zero).I am happy to do the work on the conversion, although I'm curious if @ixti has warmed up to them at all over the years as he's voiced opposition in the past.
Another nice thing to integrate with another breaking change cycle is Socketry, particularly since if we're making breaking changes to the timeout API, there might be some additional ones to consider moving to a Socketry-based timeout system.
Thoughts? @ixti @zanker @janko-m