> Installer install: 'Packages'.
>
> If you want to maintain all of the published versions of your  
> package you may prefer to load.
>
> Installer install: 'PackageAllVersions'.

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.

> If you are using squeak 3.10 the following hierarchy of classes will  
> load.
>
> 1. Packages - Abstract Base Class
>
> 2. PackagesAllVersions - Non-specific package definitions that load  
> the latest version, if that version is likely (but not 100%  
> guarenteed) to work in all versions. You don't have to wait for your  
> package to be perfect, to put a generic definition in here, enabling  
> your users to try it out in their favourite squeak version, and  
> provide you with feedback.
>
> 3. PackagesSqueak310beta - Non-specific package definitions that  
> load the very latest version, specific to 3.10. Again it is expected  
> to work, but the author may not have actually tested your  
> configuration.
>
> 4. PackagesSqueak310U - The specific exact published version in  
> Universes that is supposed to have been tested in that image version.
>
> 5. PackagesSqueak310 - The specific exact version that 'you'/'we'  
> have found 'actually' works, overriding the universes definition.


> The community can clearly identify and publish what works where, and  
> this provides a shared collective whiteboard in which active  
> collaboration can take place. In addition, if a specific version in  
> a specific image needs a patch to work, then it can actually be  
> included in the load script for that package. Thus for the first  
> time patches can be included in published packages, and released for  
> testing, without the bottleneck of waiting for the Package author to  
> get around to fixing the problem for your squeak-fork. Those who  
> submit patches will actually see their work get used immediately.


> Automation
>
> All installation scripts should run without interaction, for  
> automated installation. See 'Seaside' for an example.
>
> 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.

> Flexibility
>
> Have your own package definitions for your own squeak fork, subclass  
> to specialize/override etc etc.
>
> I declare Sake/Packages for squeak open!
>
> enjoy
>
> Keith
>
> ===
>
> btw... LevelPlayingField is currently broken in 3.8.1 and I dont  
> have time to fix it, the SqueakMap update process chokes it.
> to do: Sake/Packages-SqueakMap the same scheme for
>
> p.s. In case anyone wonders... the packages mailing list has not  
> been used for ~ 3 years. I emailed the packages mailing over a year  
> ago and discussed its use for this purpose with anyone who cared.
>
>
>
>
>