stephane ducasse wrote:
>> Installer install: 'Packages'.
>>
>> If you want to maintain all of the published versions of your package 
>> you may prefer to load.
>> Installer install: 'PackageAllVersions'.
Ok, there is a monticello package for each squeak version, so far 3.7, 
3.8, 3.9, and 3.10 but the more the merrier.
As a user of a particular version of squeak, Installer install: 
'Packages' only installs the one that is relevant for you.

If you are a package author and you want to see/edit every place in the 
Packages/Sake system in which your package has a load task and edit 
them, then you will want to load all of the packages. That what 
PackagesAllVersions does.

> Keith I try to understand what you mean by the previous statement.
> It is not clear to me.
>
> I do not understand the following one either. It seems that I missed 
> something.
>
Each "Package Load Task" is an instance method. A hierarchy of classes 
allows general package definitions at the top and more specific 
definitions at the bottom.

We start with the most generic "Package Load Tasks". Packages which will 
load into any version of squeak, and they will load the latest version 
whatever it may be.

 From there we work towards the most specific "Package Load Tasks". 
Packages which need this script to load into this particular squeak version.

In between we have the Tasks, as defined by the current Universes 
system, so these are fixed from the Sake/Packages point of view. The 
universes definition should work but is potentially out of date.

You choose which level of specificity you want like so...

(Packages currentBeta load: 'Pier') run.  "scripts defined at this level 
can be generic"
(Packages universe load: 'Pier') run. "This is a recent universes 
definition"
(Packages current load: 'Pier') run.  "this is the maintained definition"

The nice thing about this is that it can be adapt to your position in 
the development cycle. A new package that is constantly being updated 
need only be defined generically. As a package matures and more people 
are interested in stability, more specific definitions can be added.
>> If you are using squeak 3.10 the following hierarchy of classes will 
>> load.
>>
>> 1. Packages - Abstract Base Class
>>
>> Deterministic Builds (potentially*)
>>
>> All of the package definitions, for the image you are using are 
>> version controlled in monticello. So you can go back to a previous 
>> configuration from a previous date and load it. *The packages you are 
>> loading have to be listed to nominate specific packages for this to 
>> work.
>
> I do not understand the previous sentence and its implication.
>
If I load a package from Universes today it might give me a completely 
different result from yesterday.
So testing and publishing a fantastic image building script which uses 
Installer and Universes, can be broken by someone removing a package 
from the universes server.

With a Sake/Packages based installer script you can say, "This worked 
with PackagesSqueak310-kph-14".
They use can load this and all will work exactly as when you tested it. 
IFF the script uses tasks which are specifically defined.

A generally defined task is like so:

Installer squeaksource project: 'Sake'; install: 'Sake'.

A specifically defined task is like so:

Installer squeaksource project: 'Sake'; install: 'Sake-kph.15'.

does that help?

Keith
>
>