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

David T. Lewis lewis at mail.msen.com
Sat Feb 15 13:26:10 UTC 2003


On Wed, Feb 12, 2003 at 11:41:29AM -0500, Withers, Robert wrote:
> > -----Original Message-----
> > From: Daniel Vainsencher [mailto:danielv at netvision.net.il]
> 
> > So what we need is this - a patch to SMLoader such that it accepts all
> > packages for it's own version, and, if it's own version ends with
> > 'alpha', also all package for the previous version. Where previous
> > version should correctly handle nonobvious cases like 4.0. 
> > One approach
> > is to store a list of "X's previous version was - Y". Another angle
> > might be a patch to Squeak that remembers what it's previous version
> > was, though I'm not sure that should be in the base image.
> 
> Why couldn't we just present the latest version of any package as being
> suitable for loading in any later version image?  If a package becomes
> outdated, we could 'close' its version stream.
>

This sounds about right.

As a maintainer of packages on SM, I do not want folks to assume that I
will alway be available to retest and certify packages in a timely manner
every time a new Squeak version is declared.

As a user of SM, I want to be able to browse all the packages that will
probably work on my new version of Squeak.

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
 



More information about the Squeak-dev mailing list