|Kirk Haines||Aug 21, 2009 5:20 am|
|Tanaka Akira||Aug 21, 2009 7:16 pm|
|Kirk Haines||Aug 24, 2009 8:16 am|
|Tanaka Akira||Aug 24, 2009 9:26 am|
|Urabe Shyouhei||Aug 24, 2009 9:43 am|
|Yukihiro Matsumoto||Aug 24, 2009 9:51 am|
|Kirk Haines||Aug 24, 2009 10:19 am|
|Urabe Shyouhei||Aug 24, 2009 10:31 am|
|Urabe Shyouhei||Aug 24, 2009 11:57 am|
|Tanaka Akira||Aug 24, 2009 11:44 pm|
|Kirk Haines||Aug 25, 2009 11:46 am|
|Joe Swatosh||Apr 6, 2012 10:14 pm|
|Subject:||[ruby-core:25102] Re: [Backport #1975] Backport Dir.mktmpdir|
|From:||Urabe Shyouhei (shyo...@ruby-lang.org)|
|Date:||Aug 24, 2009 11:57:50 am|
Kirk Haines wrote:
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....).
I strongly agree with this. I wrote it before but "to fix a bug is to change something". Bugfixes and behavioral changes are sometimes distinguishable, but not always. On really delicate situations, I don't know a way to say which. That's one of a reason for me to believe Kirk on his decision; I may not have other tactics than that.
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.
It's *my* preference when I was the 1.8.6 mentor, but if a change itself isn't a bugfix, I might leave it unapplied. That's the policy Tanaka-san stated as "No new feature". I analyzed myself and now I think it's because I think people should move to a newer ruby in a long term. More radically speaking, I believe no new scripts should be written targeted to 1.8.6. 1.8.6 is for those scripts that has already been written for it. From that point, non-bugfix changes aren't welcomed because I want to encourage people NOT to write a script for 1.8.6.
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.
So policy differences between you and me is due to our difference in standing points. I want to make this world as ideal as I dream, while you have more realistic point of view that this world is not as ideal as I dream. People are still living on top of 1.8.6. It's true. And we decided to let you manage 1.8.6. The policy difference is easy to accept once I know this point.
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.
I don't think you should have one. What I wrote in this mail is I have a different one. Follow the path you believe.