From: Urabe Shyouhei Date: 2009-08-25T03:58:27+09:00 Subject: [ruby-core:25102] Re: [Backport #1975] Backport Dir.mktmpdir This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C75CEBADFBA1DBADC86578C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 ch= ange something". Bugfixes and behavioral changes are sometimes distinguishabl= e, but not always. On really delicate situations, I don't know a way to say whi= ch. 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 state= d 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 speaki= ng, 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-bugfi= x 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 stan= ding points. I want to make this world as ideal as I dream, while you have mo= re realistic point of view that this world is not as ideal as I dream. Peop= le are still living on top of 1.8.6. It's true. And we decided to let you mana= ge 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. --------------enig2C75CEBADFBA1DBADC86578C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqS4sgACgkQuTXPUnA5eMLBmgCbBkhL0jhjlvVhnBE/C3Vf9f2p FAMAn1yBLF9oBRPfXr7R5xYbulcFNkaL =YHr6 -----END PGP SIGNATURE----- --------------enig2C75CEBADFBA1DBADC86578C--