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(a)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.
