"Ken G. Brown" <kbrown at tnc.ab.ca> wrote:
> With respect to Craig's 'Flow', I have been thinking about the 
> inertia caused by the perceived need to make major system changes 
> backward compatible.

The principle Ken and others are stating is great.  My suggestion is
simply that we should focus on changes that really are useful.  We
should not just move things around because we think it looks nicer. 
Lots of people are building on top of Squeak, and we shouldn't cause
them grief unless there is actually a reason for it.  And we most
certainly should not break our own code all the time.  That's no way to
move forward.

As an example, renaming of classes and methods is a poor bargain.  Yes,
arguably the new names are better.  (Though arguably, in many cases the
old names were better, too!!)  This is a minor change.  This is a change
that no one will regret having seen when they are old.  But, it is a
change that very easily breaks lots of code.  Why do it?

And if we must do it for some good reason, please let's have a grace
period, and not remove the old name until -- at *least* -- the
maintained code on SqueakMap has been moved over.  Don't just pull the
rug out one day.

Overall, while we must break a few eggs as time goes on, we don't need
to jump around and stomp on the whole batch.

Lex