I did some extra thinking about this and I'm having doubts if this is the way to go. For one the spec itself doesn't have to be removed as it already contains a version guard. Second, I don't think removing this method actually helps. Once we officially implement Ruby 2.2 we'd have to then re-add it (or revert this PR), which doesn't really make things easier. Besides, keeping the method shouldn't hinder anybody.

In other words, I strongly feel we should just keep this method. In the future Ruby 2.2 changes should be submitted to the 2.2 branch instead.

I agree @yorickpeterse, we should be more diligent in the future about new additions and the branches they go on, but for now I don't think this will hurt.

@robin850 can you explain the reason you are asking for it to be removed?

Removing it now and re-adding it for Ruby 2.2 compatibility is not a problem. If the method being there is causing a problem, we should remove it.

To be honest with you nope, this is not causing any problem. This is just not logical in my opinion to have forward features. We discussed that it was a bad practice on IRC but still, people may make the assumption that if Kernel#itself is available then the current Ruby is 2.2+ so things like Float#next_float are available as well.

Anyway, there's no big deal there. This pull request was just raised because I thought it was unintentional that Rubinius already has this method. You can close it if you guys prefer no to "re-revert" this patch later ! :-)

@robin850 ah, thank you for the explanation. I misunderstood in the IRC conversation that it was causing a problem.

In general, we won't pre-release MRI features. This one got in because we didn't have a clear procedure about where the upcoming MRI features should go. They should go on a 2.2 branch for now.

Since it's not causing a problem, I agree with @yorickpeterse and @jc00ke.

Cool, no problem ! 👍