Anybody want to help us Guides fix a process bug? (was: Re: [
Fwd: Package Loader version filtering ...
dway at riskmetrics.com
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 netvision.net.il]
>> 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
> and for 3.4->3.5, was that the SM cards for the now previous image
> would not show up when using a new image version + SM. Many of the
> are sounding quite complicated, and maybe they need to be when
> dependencies of modules. However when talking about base squeak
> 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
> 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
> starts to get re-ginsued. A more rigorous dependency mechanism could
> used to check and auto-load auxiliary packages at specific version
> levels of
> support. This version info should be put in the dependency mechanism,
> 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...
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