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