From: matz@... (Yukihiro Matsumoto)
Date: 2003-01-03T01:02:16+09:00
Subject: Re: Compatibility (was Class.inherited)

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.