That distinction is somewhat blurry, though. Some of the bugfixes have introduced implicit behavioral changes, and IMHO, that is OK so long as the behavioral change is required to fix the bug, or is more correct (as in some of the recent fixes with handling of Bignums, infinity, etc....).

In general, I'm not adopting new features from 1.8.7, but where there is something that won't break existing code that depends on 1.8.6, and where there's an arguable benefit to backporting something that has already percholated through 1.8 HEAD and 1.8.7, I don't see harm in allowing that capability to fall through to 1.8.6. There are a lot of changes that can't easily move from 1.8.7 to 1.8.6 because of larger, fundamental changes to the code. In the case of Dir.mktmpdir, which is just a pure ruby addition to a class, and doesn't have a larger API that goes with it, I don't see a problem, especially since it, in turn, simplifies the test case code in at least two instances.

Contrast this with String#start_with?. That is also being used by the test_file_exhaustive.rb test set, but I won't consider backporting it because it is a far larger change that lives in the context of a number of other String class changes which are unlikely to be truly backwards compatible with existing 1.8.6 behavior. 1.8.6 should not mirror 1.8.7, because, IMHO, the progression in the 1.8 and 1.9 lines should encourage people to eventually move to those versions because of the advancements to be found there, but there are still a large number of people entrenched in 1.8.6, so modest refinements which can be backported without risk of breaking someone's code, and which offer some other tangible advantage, should be considered.

I am completely open to discussion regarding my perspective, though. If anyone thinks I should have a different policy, please speak up and tell me why.