tim Rowledge wrote:
> Here you are expressing the major problem in a group project-
> - You want everything else to stay the same so your massive changes  can 
> go ahead.
> - So does everyone else doing any work!
> 
> We simply can't make any useful progress under such conditions.  Forward 
> progress causes breakage and it costs much effort to provide  invisible 
> mogration support. Spending time on that prevents forward  progress - 
> and puts people off ever bothering.

I don't believe that is true in general. I agree there are some changes 
where backward compatibility is very hard (or basically impossible) but 
for most of the changes that's not true. Generally, I've come to opt for 
the "parallel subsystem approach" where you don't simply destroy an 
existing subsystem just because you can but rather create a parallel 
hierarchy of entities so that both subsystems can be loaded side by side.

For example, I hope that if we ever get a new set of Stream/File classes 
they would be done in a way that the old classes could be loaded and 
used side-by-side. For example, I hope that if we ever get a new 
compiler, this would be done in a way that the old compiler can be 
loaded and used side-by-side. For example, if we ever get a new set of 
tools, I would hope that... etc.

Cheers,
   - Andreas