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.

regards, Göran