From: Kirk Haines <wyhaines@...>
Date: 2009-08-25T02:20:37+09:00
Subject: [ruby-core:25098] Re: [Backport #1975] Backport Dir.mktmpdir

On Mon, Aug 24, 2009 at 10:27 AM, Tanaka Akira<akr@fsij.org> wrote:
> In article <f4cd26df0908240817s68a6835ie65d942bbd3b95be@mail.gmail.com>,
> �Kirk Haines <wyhaines@gmail.com> writes:
>
>> (*nod*) �It has been backported through the rest of the 1.8 line,
>> though, and only adds capability; it doesn't change any existing
>> functionality, so I don't see a problem with just backporting it to
>> 1.8.6. �If I am incorrect in that analysis, please let me know.
>
> It seems your maintainance policy is different from Urabe's.
> Urabe's policy is "bugfix only". �No new feature.
>
> Although policy difference doesn't mean bad in general, I
> guess the difference makes the distinction between 1.8.6 and
> 1.8.7 bit unclear.

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.


Thanks,

Kirk Haines