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 Services 
(my day job) would like to see the JWSDP released with the JDK so there 
are no issues with its use, but the JWSDP group is separate and not on 
the same schedule as the JDK.  In their case the JWSDP is moving 
faster.  For Squeak decoupling the core release schedule from package 
release schedules would allow the package maintainers to work at their 
own pace.  My understanding is that the B3D/Wonderland issues are 
resolved in the 3.8 release but were broken in 3.7.  So even though the 
core had 2 releases, the B3D/Wonderland package had 1 release (that 
worked).  By keeping their release schedule separate there is less room 
for error.

If it was up to me I would have as little as possible in the core 
platform release.  It would have the VM and the kernel, and what was 
needed to load packages.  Then everything that is packages would be on 
their own schedule.  This does require that package owners test their 
packages with the releases they intend to support.  It also means as a 
user I know what the last tested release of a package was on.  As an 
open source group I can try to load a package on a newer release, but I 
know that it was not officially tested there.  The B3D issue appears to 
have come from a package being released without adequate testing, by 
virtue of it being in "full", rather than because a maintainer 
explicitly tested it.

Michael


On Dec 16, 2004, at 4:09 PM, Yar Hwee Boon wrote:

> On Thu, 16 Dec 2004 16:02:14 -0800, Michael Latta <lattam at mac.com> 
> wrote:
>
>> That would be my advice also.  Decouple the release of the core 
>> components from the "application" components.  Just as I can not 
>> assume that application X can run in the next release of OS/X without 
>> testing or vendor assurances, the same is true of Squeak.  The fact 
>> that the core developers have source for the applications does not 
>> change the responsibilities.  Each package should go through release 
>> cycles just like the core.  If you release a 3.9 base image with just 
>> tools, then each application package can be migrated to operate on 
>> top of it.  The end result is that some applications will lag more 
>> than others.  Some applications will release new versions at the same 
>> time as core releases.  It just depends on how actively they are 
>> maintained.  But, you can not assume all packages will run on the new 
>> release.
>>
>> This is not unique to smalltalk.  I do not assume my Objective-C code 
>> works on a new release of OS/X.  I do not assume my Java code runs on 
>> a new release of OS/X, Windows, the JDK, etc.
>
> On the contrary, although other Java commercial offerings may not, new 
> version of the JDK (JSDK or whatever they call it now) and core 
> language is actually rather backwards-compatible. In fact, many people 
> have argued that this is seriously limiting the language's progress.
>
> -- 
> Regards
> HweeBoon
> MotionObj
>