Dear All,

Sake/Packages is now at a point where it is a useful resource for the 
community to contribute to. To help this along I have set the 
squeaksource.com commit emails to go to 
packages at lists.squeakfoundation.com  Discussion as to what should go 
where and whether or not specific configurations work or not can be 
directed there also. I believe that the Sake/Packages package 
definitions will be a useful resource for all of the Squeak communities.

Please join me in in this knowledge gathering exercise, please bring 
what you know about what loads where and feel free to fill in the 
package definitions. Its very easy, I updated all of 
Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.

To load Sake/Packages into a LevelPlayingField (LPF) image:

Installer install: 'Packages'.

If you want to maintain all of the published versions of your package 
you may prefer to load.

Installer install: 'PackageAllVersions'.

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.

Make it easy for Authors and Users.
==========================

Benefits for Authors - You do not have to constantly update your 
published packages all the time, you can publish a "load latest" script 
in the generic (2. 3.) levels of the hierarchy.

Benefits for Users
=============
Quality

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.

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.