On Fri, Jan 03, 2003 at 12:38:28AM +0900, Dave Thomas wrote:
> 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.

I like that idea.

In what form would this announcement be?  (for the Class#inherited
example, I don't think a warning would work, since there's no easy way
to detect how the user intended to use the function).  A list of
significant changes from version to version would be nice (trudging
through the ChangeLog isn't very helpful).

A "Matz's time machine" might also help.  This would allow users to pick
which semantics they want during the interim.  Using it might look
something like:

  require "future/some_new_feature"

Major changes in syntax or semantics should probably be allowed only in
a development version or in one of these time machine modules.  If
stable versions contain only bugfixes and new features, then this makes
migration to a new (more-bug-free) version much easier.

Paul