> I declare Sake/Packages for squeak open!

Great. It leaves only one question open: What *is* "Sake/Packages for 
Squeak"? You are describing nicely everything around it just not what it 
is... some clarification would be welcome ;-)

Cheers,
   - Andreas

Keith Hodges wrote:
> 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.
> 
> 
> 
> 
>