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.

Michael




On Dec 16, 2004, at 2:07 PM, Giovanni Giorgi wrote:

> Hi,
>  I agree with you.
> I think  it is very difficult to build stable package on smalltalk
> because of the high dynamic coupling between core parts and the rest of
> the system: the beauty of smalltalk is the ability to add powerful
> concept (like Object Database, dynamic-proxy and so on) changing only
> some core methods.
>
> This can lead us to a lot of difficults when trying to integrate hot
> stuff.
>
> As Celeste mantainer I am quite happy to have time to integrate my
> package in my spare time: if Celeste was in the base Image, I cannot
> afford easily it :)
>
> I think we can try to split our work in two truck:
> -a fast approaching base image (very core stuff, with new VM
> improvements and so on).
> -a less fast "application" truck, which do a strong s-unit.
>
> So everyone can choose its speed...and eventually furnish two update
> stream also...
>
> my two cents :)
>
> --- Bill Schwab <BSchwab at anest.ufl.edu> wrote:
>
>> Hello all,
>>
>> I've been trying to follow this thread, and I find myself agreeing
>> (and
>> disagreeing) with people on both sides of it (might be better to say
>> all
>> sides of it<g>).  A few random thoughts:
>>
>> (1) Those concerned about the dynamic nature of Squeak might do well
>> to
>> tune out of the update streams, or at least stay clear of the alpha
>> versions.  Either way, add lots of unit tests.  In that regard, I
>> [...]
>
>
> =====
> // Giovanni Giorgi    http://www.siforge.org
>