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@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.