Hi,
In message "Compatibility (was Class.inherited)"
on 03/01/03, Dave Thomas <dave / pragprog.com> writes:
|This raises a somewhat bigger question.
<snip>
Your worry is understandable. Unofortunately <g>, the wider Ruby
used, the less incompatibility allowed.
|As a starting point for discussion: how hard would it be to make it a
|rule that all incompatible changes are introduced in two phases. In the
|first, the interpreter would announce that the behavior will change, and
|then in the second (say 3 months later) the change will be introduced.
|That would allow us to run our existing code against the interim
|release, and give us time to fix things up before the change is made.
OK, I will soon freeze 1.8 feature change, and list 1.8 changes
(actually all I need to do is just translate the Japanese change list
in <http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=ruby+1.7+feature>).
Then, I will wait for two or three months of preview time. This
pattern should be kept in the future.
By the way, back to the original issue; after examining the change
history, I found out *that change was wrong*. I will back it up to
the original 1.6 "inherited" behavior.
matz.