> That doesn't solve this problem. The loader script on SqueakMap uses an
> unspecified version of ConfigurationOfOmniBrowser. This shouldn't really be
> a problem, but the version where I fixed the Squeak (and some Pharo) part of
> it was simply ignored by others (Pharo devs). So loading the newest version
> of ConfigurationOfOmniBrowser via Installer won't work for Squeak. Other

One of the concerns we've had about legacy packages relates to when
the primary maintainers of those packages have departed the community.
 For this, there seemed to be consensus that it would be "ok" to add
additional releases that were up-to-date for the most current versions
of Squeak - leaving the original authors legacy work (for old Squeak
versions) intact.

I think we should consider expanding this to include projects for
which we can't get action.  The goal is to provide working software
packages for modern Squeaks - so what's the difference between someone
who has "departed" vs. someone who does not have time / inclination /
whatever to assist with keeping their package up to date?

I sent private e-mails months ago to several folks who are not
departed regarding projects which are in Extending the System
workspace about pasting them into the SM Catalog scripts.  But when
those e-mails are ignored, Squeak suffers for no good reason.  I'm
trying to do the polite thing by letting the owner take responsibility
but, that failing, maybe we should have a warning-protocol which would
eventually allow us to take matters into our own hands.  To reiterate,
the CSP security of SqueakMap only allows _adding_ of new CSP releases
(which can then be udpated in case of bugs, etc) - not updating the
authors original releases.

What do you think?