Hi guy

I do not have the time to follow the detail and I'm sure that you are 
trying to find the best.
The big point I want to stress again is that as a book writer for 
novices I would like that
reader can download an image fun, full of stuff and looking a bit 
similar from the external point of view to the 3.5. I also think that 
the best think to find bugs is to let people play with them.
So I would go for the solution 3 even if I dream about a mini image 
with a script to only load what ***I*** want with dependencies and 
clever versioning.
So you see I'm a person concerned by two different aspects of Squeak.

Stef


On Tuesday, August 19, 2003, at 01:25 AM, Doug Way wrote:

> goran.krampe at bluefish.se wrote:
>
>> Doug Way <dway at riskmetrics.com> wrote:
>>
>>> 1. The original (?) plan:  Keep the 9 removed packages out of the 
>>> update stream.  When we move to gamma, the current update stream 
>>> image becomes the "Basic" release, and then the 9 packages are added 
>>> to this release to form the "Full" release.  The Full release is the 
>>> one provided on squeak.org, although the Basic release is also 
>>> available on the ftp site.
>>>
>>
>> The only problem being that if you download Basic image and install 
>> the
>> 9 removed packages through SM they may have changed since 3.6 was
>> finalized. The classic problem until SM2 arrives.
>>
>> It could be solved by simply not changing those 9 packages for a 
>> while.
>> :) Sure, a hack because we don't have SM2 yet. Another hack is to
>> duplicate those 9 packages with names like "XXX 3.6 release". Also a
>> hack.
>>
>
> Whatever we do, we need to handle the "classic SM1.0 problem" of not 
> having package versions somehow for 3.6.
>
> I think your idea to duplicate the 9 packages with "XXX 3.6 release" 
> may be the best option, since we'll probably need to change at least 
> one of the packages in 3.7alpha before SM2 is ready.
>
>>> Also, one other thing to think about is how things might be 
>>> different when we have SqueakMap 1.1, and we get to release 
>>> 3.7final.  SM 1.1 will support versions and 
>>> dependencies/configurations on top of that, which solves some 
>>> important problems, but I'm not sure if it resolves the issue we're 
>>> talking about here... at least not while we're still chopping away 
>>> at the image.  We'd still like a way for a largish number of people 
>>> to test a beta Full image/configuration before it goes final.
>>
>> Well. First of all SM2 will most importantly support releases of
>> packages and have a proper cache. Those two things solves the problem.
>> Package releases means we can release a Basic image and then publish 
>> one
>> or more loadscripts that installs *specific versions* of packages. 
>> These
>> loadscripts will not change over time when the packages change because
>> they refer to package *releases* and not just packages.
>>
>
> Yes, SM2 will solve the most important problems.
>
> What I meant when I said I'm not sure if SM2 "resolves the issue we're 
> talking about here" is the "problem" of allowing people to really 
> easily maintain a Full image which follows the alpha update stream... 
> I think this is what Michael was getting at.  There is some 
> disagreement as to whether this is really an important problem or not. 
> :-)  It seems to be important to some, not so important to others.
>
> I think it's probably understood by most people that, long-term, there 
> won't be a single update stream for an image to simply follow along, 
> because the image will be broken down into a bunch of packages.
>
> However, for the short and medium-term, I think we probably could 
> still support a Full release following an update stream reasonably 
> well.  What do you think about the "option 2.5" that I suggested 
> earlier?  (Adding an update-stream prompt for people to upgrade back 
> to Full if they want, but keeping a single update stream.)  I think 
> this might be the best compromise, because it really doesn't harm the 
> Basic image update stream.  The update stream will still primarily 
> follow the Basic image, but people can use the same stream with a Full 
> image also if they want.
>
> People using the update stream with a Full image may run into some 
> problems, but if we're strict about not allowing any Squeak-Official 
> packages to overwrite any methods in the base image (or in other 
> packages), the problems should not be too severe.  The remaining 
> problems would basically be load-order problems resulting from 
> arbitrary do-its, or when loading/initializing classes.  If we try to 
> avoid overuse of do-its and class initialization magic, hopefully 
> things will generally work for people updating Full images.
>
> Of course, for Full image users, problems may come up in the 
> (currently 9) Squeak-Official packages because of changes in the base 
> image.  There might be a short lag before the package is updated.  
> This is no worse than the current situation, and hopefully these bugs 
> would be found sooner since more people would be casually using things 
> like Scamper in full alpha images.
>
> Michael and others, does this sound like it would reasonably support 
> folks who wanted to stay in the Full image environment?
>
> Hmm, I guess you are right that SM2 will significantly help this 
> problem too, because we'll also have user accounts so that if one 
> maintainer is not that responsive to making a small fix to a package, 
> perhaps another maintainer could get to it faster.
>
> - Doug
>
>
>