Anybody want to help us Guides fix a process bug? (was: Re: [ Fwd: Package Loader version filtering ...

Doug Way dway at
Thu Feb 13 04:07:55 UTC 2003

On Wednesday, February 12, 2003, at 05:13 PM, Withers, Robert wrote:

>> -----Original Message-----
>> From: Daniel Vainsencher [mailto:danielv at]
>> Not sure I understand what you mean. Note that SM uses
>> categories right,
>> and SM loader simply checks whether the current squeak version matches
>> one of those categories for each package.
> The SM issue that occurred when the image version changed, for both 
> 3.2->3.4
> and for 3.4->3.5, was that the SM cards for the now previous image 
> version,
> would not show up when using a new image version + SM. Many of the 
> solutions
> are sounding quite complicated, and maybe they need to be when 
> discussing
> dependencies of modules.  However when talking about base squeak 
> versions,
> all cards should show up if they have been registered for any previous
> version of base squeak.
> For example, I look at Connectors and SM has required that categories 
> be
> installed for #('Squeak3.2.1' 'Squeak3.4' 'Squeak3.5'), so that it 
> works on
> all of those systems.  My proposal is that you just need to enter
> 'Squeak3.2.1' and any later base image versions will be able to see 
> and load
> that SM entry, without the package maintainer having to add yet another
> category, for each new image release.  This is especially true as the 
> image
> starts to get re-ginsued.  A more rigorous dependency mechanism could 
> be
> used to check and auto-load auxiliary packages at specific version 
> levels of
> support.  This version info should be put in the dependency mechanism, 
> but
> not in the card-catalog system.

Ok, I see your point, but I don't think we should do this until the 
dependency mechanism is in place and widely used, and the image is 
completely "ginsued". ( ;-) )  This probably won't be for awhile... 
definitely post-3.5.

Until then, I think we need to rely on base squeak versions as a sort 
of poor-man's compatibility mechanism in the Package Loader.

Most reasonably complex Squeak packages are often not 
backward-compatible nor forward-compatible between Squeak versions.  
For example, I'm guessing that the Refactoring Browser as written for 
Squeak 3.0 did not work properly in Squeak 3.2.  I know that was also 
true for Whisker.

Given that, I'd prefer to have the package maintainers be forced to 
verify that their packages actually work in the newer Squeak version, 
and add the new version to their package in SqueakMap when necessary 
(which is pretty easy).  Otherwise, the default view in the SM Package 
Loader would show a lot more packages than it does now, many of which 
would not work when you installed them. (kind of like the projects on 
the superswiki ;-) )  (And remember this is just the default view we're 
talking about, you can always show all packages and try installing any 
one if you want.)

But yeah, once we have the image split up into packages and a 
dependency mechanism in place, it would probably be okay to list older 
packages by default, because the dependency mechanism would take care 
of loading the proper prerequisites, so that things would work.  (Or it 
would at least prompt you about whether you wanted to load the 

- Doug Way

More information about the Squeak-dev mailing list