"Stephen Pair" <spair at acm.org> wrote:
> I just rolled an image to 3.4a and noticed that YAXO is now in the
> stream...why?  Aren't we trying to make things more modular and move away
> from the kitchen sink image approach?  This would seem to work against that
> direction.

I think it sneaked in before this new focus was started. I think even
Michael has said it will probably go out pretty soon again. :-)

> Why not start a SqC Squeak distribution that has its own set of packages
> pre-loaded and keep the contents of update stream to a minimum?  (in fact,
> maybe we should make a rule that change sets in the update stream should
> yield a net reduction of the code base in the base squeak image)...ok, I'm
> exaggerating a bit here, but is the idea valid?

It is valid and this IS the idea from now on.

> I imagine if you started packaging things like YAXO into SARs (with a change
> set and DVS package), then you could quickly qet to an automated build
> process where you take a fully up to date image and load the various
> packages for the SqC distribution...and perhaps do it nightly.  The only
> issue then is versioning the packages (which I think we could use my
> VersionNumber (http://minnow.cc.gatech.edu/squeak/2511) stuff to give
> package file names a version number...this could be optional with DVS if you
> want to use a version naming conventiong instead of CVS...it would allow you
> to handle the case where two people concurrently work on version 1 of a
> package and both try to file out their changes (the first one to file out
> would be "packageXYZ-2.st" and the second would be "packageXYZ-1.1.st").
> Merge tools could be added at a later date.
> 
> VersionNumber and VersionHistory would allow a build script to say "give me
> the latest mainline version of packageXYZ" (VersionHistory can be inferred
> from a simple directory listing of everything matching "packageXYZ-*.st").
> You then just ask your VersionHistory instance for the latest mainline
> version.
> 
> So, I see 3 simple additions to DVS that might be useful...
> 
> 	a) allow a change set to be added as a preload to a package (for changes to
> external packages to be separated from things that actually belong in the
> package)
> 	b) have DVS use the SAR format for externalizing packages (so that the
> change set and *.st file can be maintained together)
> 	c) have DVS incorporate VersionNumber (and show the version number in the
> package browser) as an optional way of naming packages and thus keeping
> version history
> 
> A nightly build script could then simply say: take the latest image, load
> the latest versions of packages A, B, and C, load and execute SUnit
> packages, and if everything looks good, save the image to an ftp download
> site.
> 
> - Stephen

I am planning adding configurations to SM, in fact two different kind of
such beasts. And one of them is what I call an "image configuration"
which could also be called a distro. It is along these lines.

regards, Göran