god icon indicating copy to clipboard operation
god copied to clipboard

Object#timeout is deprecated warning

Open Nick-DeSimone opened this issue 9 years ago • 8 comments
trafficstars

I received the following warning when God starts up:

/usr/local/rvm/gems/ruby-2.3.0/gems/god-0.13.7/lib/god/system/slash_proc_poller.rb:64:in `readable?': Object#timeout is deprecated, use Timeout.timeout instead.

I realize this is just a warning, but I wanted to get it on the radar and I don't have time in the project to stop and try to address it myself.

Nick-DeSimone avatar Feb 26 '16 14:02 Nick-DeSimone

I met this warning too.

li-thy-um avatar Mar 08 '16 08:03 li-thy-um

I started getting the warning when upgrading from ruby 2.1.8 to 2.3.1.

groe avatar May 17 '16 13:05 groe

I submitted #235 but there are issues with Travis CI and the old Rubies that god supports. IMO those should be dropped, I don't think it's worth the time to keep them supported.

boone avatar May 17 '16 18:05 boone

I don't think <1% usage of 1.8.7/REE are worth any extra effort for the future development of god. Can we drop support for those versions?

groe avatar Feb 01 '17 15:02 groe

Ruby 1.8.7 is still the default ruby on CENTOS/RHEL 6 and will still be a supported distribution until 30 November 2020.

Having something to manage processes not work with the system ruby seems like a bad trade-off to me.

eric avatar Feb 01 '17 21:02 eric

Ruby 1.8.7 and Ruby 1.9.2 were EOL as of July 31, 2014. It should be noted that Ruby 2.0 is also in EOL and Ruby 2.1.X will only receive security updates. Waiting to drop it until 30 November 2020 will only make things harder and harder as new versions of Ruby are released and more go into EOL.

I understand trying to make things as easy as possible for users who still need support, but IMO it's just as feasible to bump the gem version and note that support will be dropped for 1.8.7 and users can keep using previous releases. It's not optimal, but it should be understandable.

dpostorivo avatar Feb 01 '17 21:02 dpostorivo

Are there things that are provided in newer rubies that would be a big win for the project? I definitely see value in getting rid of deprecation warnings (even if it's through small compatibility changes), but I'm not sure that (for instance) being able to use the new hash syntax in the project is worth the trade-off of no longer working with system rubies that are still in the wild.

eric avatar Feb 01 '17 22:02 eric

I agree, the new hash syntax alone would not be worth it. However getting rid of deprecation warnings plus the new hash syntax exceeds the (IMO not very high) threshold of dropping support for a 9-year-old, EOL ruby - even if it's the system ruby on CENTOS/RHEL 6. I also work with RHEL 6 from time to time and the first thing I do is install rvm for that reason.

There might be even bigger wins with 1.9+, I don't know the internals of god well enough to assess that.

Also, we could add a note to the README to let ruby 1.8.7 users know which god version still supported it?

groe avatar Feb 02 '17 11:02 groe