I agree exactly with everything said, including Stefs comment here - I
think it's a good, gradual form of transition. 

3.5 could be the first version where things start to actually
"disappear" in mass, including everything that's been ready from 3.4.

By then SM configurations will be both ready and well known, and
building images will be easy for whoever wants to, including the Guides,
if that turns out to be necessary (I think this is definitely something
the community could decentralize completely).

Daniel

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Hi doug
> 
> My impression is that 3.4 should be an improved version of 3.2 with 
> some of the architecture ready to
> start shrinking: dynamic menu, new filelist architecture, new events....
> and some systems ***removable*** but still in the image. (Except for 
> the stuff andreas just mention that are obsolete).
> 
> I think that having always a miniImage and a preconstructed one would 
> be good. the idea been that the
> preconstructed should also be constructed from the miniImage (and not 
> the inverse using shrinking procedure).
> 
> Stef
> 
> 
> 
> 
> 
> On dimanche, novembre 17, 2002, at 06:12  am, Doug Way wrote:
> 
> >
> > On Friday, November 15, 2002, at 07:57 AM, danielv at netvision.net.il 
> > wrote:
> >
> >> If think we are in violent agreement then. Lets review -
> >>
> >> * Code is refactored to make a complete package that requires no other
> >> code changes to load/unload.
> >> * Refactoring is posted for feedback (on list or SM) as needed.
> >> * When it's acceptable the code is inserted into update stream, so 
> >> that
> >> code becomes removable using "remove category" in the simple case or 
> >> DVS
> >> if there are class extensions.
> >> Then (Some unspecified time after the package starts living in SM...)
> >> * Update is issued that performs the remove, asking the user if he 
> >> wants
> >> to reload from SM, or leave his version loaded (in case he has
> >> modifications).
> >>
> >> Comments?
> >>
> >> If none and the it's ratified by the Guides, this will become our
> >> current policy for removing things from the image, and I'll put it on
> >> the swiki and expand on the details, and we'll do it to PWS first, 
> >> and then
> >> to whatever we get good unload code for.
> >
> > Sounds generally good to me.
> >
> > I also assumed that the update stream would simply remove carved-out 
> > packages (with a confirmation prompt).
> >
> > But Ned's question about that made me think:  Let's say the update 
> > stream, on the way to 3.4, unloads PWS, Celeste, IRC and Balloon3D.  
> > Does that mean the official 3.4 release image on squeak.org does not 
> > include these items?  Or should we provide this as the (very loosely 
> > termed) "minimal" 3.4 image, and then also provide a "kitchen sink" 
> > 3.4 release which includes these items?
> >
> > In the case of 3.4, maybe these two releases aren't different enough 
> > to bother providing both.  But if we only provide the minimal image, 
> > some people might be confused to see that the 3D demos with Alice & 
> > Balloon3D are no longer already in the image.
> >
> > People updating their 3.4alpha image all the way to 3.4 should end up 
> > with something equivalent to the 3.4 minimal release (assuming they 
> > say Yes to all the removal confirmations).  I guess this should be 
> > fine.
> >
> > Also, we will probably want some sort of SqueakMap category to 
> > indicate that the Balloon3D package is "blessed" as part of the 
> > kitchen sink 3.4 release.  (I guess this was brought up earlier.  
> > Perhaps an SM category could be "Squeak Central Release" or something 
> > like that, to indicate that the package was part of the original SqC 
> > series of releases.)
> >
> > - Doug Way
> >
> >
> >
> Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
> http://www.iam.unibe.ch/~ducasse/
>   "if you knew today was your last day on earth, what would you do
>   different? ... especially if, by doing something different, today
>   might not be your last day on earth" Calvin&Hobbes