Michael Latta ha scritto  in data 17/12/2004 1.39:

> I am not arguing against backward compatibility (though there is a 
> cost in that as the Java community is learning).  What I am saying is 
> that when a new JDK is released it is not coupled to the release of 
> NetBeans, or Eclipse, or even JWSDP.  Someone focused on Web

This is true. The fact is that a commecial product (like JDK or 
M$-Windows) should be "quite" back compatible with at least its previous 
release.
We should take care of this, to encourage developers!
 For example JEdit and Eclipse changed they Plug-InAPI about 2/3 time, 
and this require a very active community.
Older plugin gets unusable!
On thge other side Perl 5 tries to be a lot nice with old perl code, and 
Perl 6 will sacrifice only the minimum compatibility.
PHP porting from v2 to v3 or v4 is known to be a nightmare, because they 
changed the SCOPE of the variables :)

> [...]For Squeak decoupling the core release schedule from package 
> release schedules would allow the package maintainers to work at their 
> own pace.

I completely agree. This could be the goal, the essence of the "Base 
Squeak Image": fast as a rabbit :)
Then we can have a "Rock Solid" released about every two or four base 
Squeak release.
It will have the same version number but the "RS" after.
For example:

    Squeak 4.0RS
    Squeak 4.1 (base)
    Squeak 4.2 RS
    Squeak 4.3 (base)
    Squeak 4.4 (base) <--- Example of delayed Rock Solid release
    Squeak 4.5 RS

This would mirror the Linus way of organizing the Linux Kernel.
(Note:  will not have two release with the SAME number, to avoid confusion)
The RS'd have: a Release notes Workspace and some nice stuff for 
developing already installed.
The base image'd be "naked" and only for developers: they can choose 
they tools to configure it.



-- 
     Giovanni Giorgi           http://www.squeak.org
                               http://www.siforge.org
.............................................................