This starts to push the boundaries a bit...

The resolv.rb library in particular is a bit of a challenge because the differences from 1.9 to 2.0+ are substantial: https://gist.github.com/5742f26a702354379af8

This is further complicated by the fact that MRI (from which we get this library) no longer supports 1.9.3 except for security fixes, and those will end in a bit over a month.

JRuby 9000 (the next major JRuby, being developed on master) supports Ruby 2.2-level compatibility, but it is not yet released (though we hope to do so very soon).

So I'm not sure what's best for JRuby users. Updating resolv.rb could introduce incompatibilities for existing users that depend on it being the same as 1.9.3, or it may be a transparent upgrade. The only way to know may be to have someone familiar with DNS and/or this library go over that diff and decide if the changes are benign enough.

Actually after looking at the bug you linked, that patch does apply cleanly to a 1.9.3 resolv.rb. I had initially thought we'd need to pull in the entirety of changes to get this one. Those more extensive changes must have happened after this patch was created.

That lessens the impact considerably. The only concern that remains for me would be the peripheral impacts of such a change: code in the wild that runs on JRuby's "1.9.3" but not MRI's, code that patches or extends this class in a similar way that would start to break.

What do you think, @enebo?

Can this just be a separate library? Or does this depend on how other libraries load resolv? I would even think perhaps require 'resolve-timeout' after 'resolv' which minimally changes the timeout aspect (that gist appears to have other significant changes like changing the base error class). Granted, that is a monkey patch.

I do not think many/any people extend resolv but if they did this would cause a mismatch. In my mind, I would prefer people work-around 1.9.3 being frozen and not have us potentially piss off other users by breaking their code. With that said, most gems need to be forward-compat so libraries will have to deal with these changes in 2.0 if they want to continue also working in 1.9. That is not to say they will work if we change this, but it does say they already acknowledged that they have had to make changes to their libs for resolv changes. I am not really sure on this one. I usually use the rule, when in doubt leave it out?

+1 on keeping 1.9.3 in frozen/alignment with MRI 1.9.3 since it keeps a solid expectation of what "1.9.3" behaves like. A separate library to workaround this is fine with me. For context, I've done work in the past to workaround Resolv api changes between 1.8.x and 1.9.x, so continuing this work seems like not a serious burden on me.

(This might be a task worth including in https://github.com/marcandre/backports)

Closing since the prevailing opinion seems to be that it's not a good idea to change this in 1.9 mode.

If we have 2.0 resolv.rb in 2.0 mode, that would be an option for you (and if we don't, it would make a good PR).