Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Object#timeout is deprecated warning #232

Open
Nick-DeSimone opened this issue Feb 26, 2016 · 8 comments
Open

Object#timeout is deprecated warning #232

Nick-DeSimone opened this issue Feb 26, 2016 · 8 comments

Comments

@Nick-DeSimone
Copy link

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.

@li-thy-um
Copy link

I met this warning too.

@groe
Copy link

groe commented May 17, 2016

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

@boone
Copy link

boone commented May 17, 2016

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.

@groe
Copy link

groe commented Feb 1, 2017

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?

@eric
Copy link
Collaborator

eric commented Feb 1, 2017

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.

@dpostorivo
Copy link

dpostorivo commented Feb 1, 2017

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.

@eric
Copy link
Collaborator

eric commented Feb 1, 2017

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.

@groe
Copy link

groe commented Feb 2, 2017

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants
@eric @boone @groe @li-thy-um @dpostorivo @Nick-DeSimone and others