Drop 1.9 support

[zanker]

@tarcieri @sferik @ixti

With JRuby 9.0.0.0, we now have a path forward on using Ruby 2.0+ syntax/code. Given MRI 1.9.3 is EOLd, I think we should drop support for MRI 1.9/JRuby 1.7. It lets us clean up code by using 2.0 syntax/features too.

[tarcieri]

+1

[ixti]

+1

[tarcieri]

@sferik what are you plans for continued 1.9 support in the twitter gem?

[sferik]

what are you plans for continued 1.9 support in the twitter gem?

Currently, the master branch still promises to support Ruby 1.9.3. This branch will eventually be released as version 6.0.0 and has been in development since November of last year (before Ruby 1.9.3 was EOL’d in February of this year). Since the next release will be a major version anyway, I could take that opportunity to drop Ruby 1.9.3 support.

In the past, my tendency has been to support older versions of Ruby—even past their official support date—if they are still widely used. According to the 2015 Ruby survey, 6.9% of respondents still use Ruby 1.9.3. The current release of the twitter gem (version 5.x) still supports Ruby 1.8.7. I realize this may be enabling bad security practices, but there are some use cases I care about where security is not the most important thing. For example, if someone is just learning to program on a Raspberry Pi that has an old version of Ruby installed, I don’t think it should be necessary for such a user to update Ruby on the Raspberry Pi before they can start using the twitter gem. So I think it’s worth talking about the specific costs and benefits.

It lets us clean up code by using 2.0 syntax/features too.

@zanker Specifically, which features are you interested in using here? Is the plan to change all of our public interfaces to use keyword arguments? Do you have a need for Module#prepend. I assume we’re not going to start using refinements.

[tarcieri]

Let's keep supporting 1.9 for in 1.x releases and reopen this if there's a legitimate Ruby 2.0+ feature (e.g. keyword args) we'd like to take advantage of in a http 2.x gem

[tarcieri]

Okay, well there are some legitimate 2.0+ features to look at, so I'm reopening this and setting it for the 2.0 milestone (i.e. all 1.x releases will support 1.9.3).

Ruby 2.0+ support IO#wait_readable and IO#wait_writable if you require io/wait. This would be a nice replacement for our current usage of IO.select.

We could perhaps gate usage of this on the Ruby version (i.e. use IO.select on 1.9.3 and the new wait APIs in 2.0+)

[sferik]

I withdraw any objections to drop support for Ruby 1.9.

[tarcieri]

Haha, right after I release 1.0 😉

Let's definitely plan on a 2.0 release of the gem being Ruby 2.0+.

[tarcieri]

So I was just talking to @ixti offline about the usage of io/wait. We ship an IO.select-based timeout backend specifically for Ruby 1.9.3 compatibility.

I'd like to drop that whole thing as well. Curious to hear opinions on how to do that in respect to semantic versioning and so forth.

I'm down to ship a "2.0" that does nothing but drop support for 1.9.3.

[ixti]

I'm OK with shipping 2.0.0. It makes gem look more mature...

Side note. Drop of ruby 1.9.3 support means only drop of jruby 1.7 as well.

[zanker]

I'm fine with that. Most of our apps are either off JRuby or on 9k so not a big deal to me to drop 1.7

Sent from my iPhone

On Jan 31, 2016, at 16:02, Alexey Zapparov [email protected] wrote:

I'm OK with shipping 2.0.0. It makes gem look more mature...

Side note. Drop of ruby 1.9.3 support means only drop of jruby 1.7 as well.

—
Reply to this email directly or view it on GitHub.

[sferik]

👍

[tarcieri]

master is now blissfully Ruby 1.9-free