+1

Two points to add:

1) The code that Cees is suggesting removing is going to rot in the 
image just as much as it will rot in a package if nobody maintains it. 
The only difference is that people who download the image will expect 
that it works.

2) I think the point that you don't have to upgrade to the newest 
version is particularly apt.  It's not like choosing to upgrade your 
version of Windows or your Java libraries where every application 
suddenly needs to work with the new libraries at once.  To me it seems 
obvious that in that case, maintaining backwards compatibility is more 
important.

In the case of Squeak, you have an image that has all your dependencies, 
your application code, your development tools, everything all together 
and working.  You can have a dozen applications all running side by side 
  that don't get in the way of each other.  At one point, with the CV 
application Andrew and I were developing, we started wishing we could 
easily upgrade to get some of the new UI features but it just wasn't 
important enough.  If it had been, we would have put in the work to 
upgrade.  Since it wasn't, the CV app is still happily running (as far 
as I know) two years later on the same system.


At some level, this discussion seems pointless because I can't imagine 
everyone ever coming to agreement on it.  Some people just see 
"(back/for)-wards compatibility" as some inately good and necessary 
thing.  I think it's a great thing to have when possible but geez, let's 
throw away the file and network code already.  As far as I'm concerned, 
the only thing standing in the way is some people having enough free 
time to do it right (and the fact that not everyone agrees with this 
position :) ).


Julian

Cees De Groot wrote:
> I say: old, unmaintained code should be ejected from the image. Kick
> Alice out. If no-one takes it up, that probably means that it is not
> important enough. Kick MVC out. Kick all the games out. Let'em be
> adopted or rot. Somehow, I think that this will serve as a
> self-selection of interesting code because I am quite sure that
> *someone* out there wil have enough interest in Alice to either step
> up and adopt the code, or - if it is an end-user - rally for support
> to have it maintained. Think voting with your feet...
> 
> I say: compatibility is not a major goal. It's nice to have, but
> shouldn't become a burden. Because if we introduce major breakage (say
> by kicking out everything files and network, loading flow, and
> declaring that the next version of Squeak), you have two options:
> - Stick with the current version for the duration of your project
> (every single Squeak version ever created is still downloadable from
> Squeak.org - no-one is putting a Colt .45 to your head shouting that
> you must upgrade or die);
> - Swallow the 2-4 hours of time and upgrade.
> A well-factored project will have only minor impact if, say, the
> network layer API changes. If your code really suffers, it was time to
> refactor it anyway. Don't blame the maintainers of the files/network
> kernel for your bad code, and certainly don't put the burden of your
> bad code on their shoulders by opposing compatibility breakage if that
> results in a better Squeak...