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

Doug Way dway at riskmetrics.com
Sun Feb 16 21:47:03 UTC 2003


On Saturday, February 15, 2003, at 11:17 AM, goran.hultgren at bluefish.se 
wrote:

> Hi all!
>
> "David T. Lewis" <lewis at mail.msen.com> wrote:
> [SNIP]
>> So the heuristic would be as Robert describes: If the package was
>> certified to work on a prior Squeak version, and if nobody has 
>> explicity
>> said that it will not work on the newer version, then show it to me.
>>
>> One refinement that might be helpful: As a package maintainer, I would
>> like to be able to explicitly declare my package as "not certified for
>> Squeak versions beyond X.Y.Z". For example, I would like to take the
>> default heuristic that OSProcess will probably work in future versions
>> of Squeak even if I have not explicitly said so (it probably will).
>> And I would like to declare that IOHandle is uncertified for versions 
>> of
>> Squeak beyond 3.4 (IOHandle messes with system classes and would not
>> be safe to load without serious testing).  Later on when I get run 
>> over
>> by a truck and stop updating OSProcess, somebody else can set the tag
>> for OSProcess to declare it "not certified for Squeak versions beyond 
>> 7.3".
>>
>> This could be done by letting the package maintainer declare a package
>> to be "probably upward compatible in future Squeak versions" or 
>> conversely
>> to "set the fragile bit" to indicate that the package is probably 
>> dangerous
>> to load into future Squeaks.
>>
>> Dave
>
> Just a little note of interest: The upcoming SM1.1 will in fact give 
> you
> similar capabilities as described above. In the modular future a 
> package
> will not depend on an image, but instead on other core packages. And
> when they evolve the new versions will have a "compatibility level"
> assigned by the maintainer. This will give the user an opportuinity to
> decide if a package will have a good chance of working even if the
> maintainer hasn't had the time to verify it yet.
>
> And btw - we shouldn't build an elaborate system around the "Squeak
> version" categories (IMHO) since they will not necessarily be used 
> later
> when the image is split up into packages.

Right.  This is why I think we should just add the fix you suggested 
for SMLoader, for now.  (And either get rid of the 3.3alpha version 
category or add my extra hack.)  It's reasonably simple (only changing 
one method), and does roughly the right thing, for a short-term fix.

Later, once the image is split up into packages with dependencies 
(which will really do the "right thing" :-) ), we won't need that fix 
anymore, and we might not need the "Squeak version" categories anymore 
either.

- Doug Way



More information about the Squeak-dev mailing list