3.6 Full release testing (was Re: [BUG]? Upgrade to full image
ducasse at iam.unibe.ch
Tue Aug 19 07:04:23 UTC 2003
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
So you see I'm a person concerned by two different aspects of Squeak.
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
>> 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
>> :) 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
> 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
>> or more loadscripts that installs *specific versions* of packages.
>> 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
More information about the Squeak-dev