Hi Hannes,

> Thank's for bringing up this topic again as a new thread.
>
> As a help to make this discussion easier,
> let me bring a specific example, the code snippet in "Extending the
> System" for loading Seaside loads a particular version of OmniBrowser.
> Currently it has a problem which it didn't have some time ago.

I just tested loading Seaside from SqueakMap into a stock Squeak 4.2
image.  It worked.

Scripts which load fixed configurations (e.g., with hard-coded version
#'s) are tagged in SqueakMap as working with a particular legacy
version of Squeak.

By "fixed" I mean, with hard-coded version numbers of the individual
packages.  By "legacy" I mean a past-release of Squeak that will
undergo no more updates.

These are the circumstances under which a library of software with
longevity can be established.  By "longevity" I mean, it represents a
combination of software components (legacy image + hard-coded version
#'s) that can be expected to work for a long time (theoretically,
forever).

I don't think it is reasonable to have this expectation for a moving
target - e.g., Squeak 4.3 alpha.  Once 4.3 is released and becomes
"legacy", then yes, we can.  But not until then.

Therefore, I prefer to associate the "head" release of various
packages with the latest alpha release of Squeak - and which may or
may not work with prior versions of Squeak.

Since the alpha release of Squeak is the one we are actively working
on, and the head release of packages are being actively worked on, we
should occasionally expect loading problems.

> So "Extending the system" servers as a constant reminder to check if
> the main "community supported" applications still work.

Each SM package (Community-supported or  not) is tagged with the
version of Squeak it is known to work with.  As new versions of Squeak
come out, new version tags are added to SqueakMap, of which there are
no members.  I see the resulting blank list as the reminder of what
hasn't yet been tested on the newest Squeak version.

> I assume most of the 773 packages on SqueakMap do not load properly
> anymore.

They (should) load into the version of Squeak they are tagged to load
into.  You need to leave the filter on, and just look at the ones that
are designated to load into the version of the image you are running..

> Keep on the good work with getting SqueakMap into focus again. But
> please note that this is not done by getting rid of the "Extending the
> system" workspace but rather by maintaing the load scripts there (with
> a copy of them SqueakMap).  We do not have a proper mechanism yet
> (technically or workflow ) to keep the SqueakMap entries current. Of
> course suggestions and helps on this are welcome.

Extending the System workspace is totally redundant with SqueakMap.
We DO have a technical and workflow solutions to keeping SM entries
current - I'm not sure what you mean by saying we don't..

 - Chris

> Note 1:
> BTW We had a discussion on this a year ago for example under the
> subject 'About configurations'
>
> And there I found remarkable note by Andreas Raab; rhe reason for the
> existence of the "Extending the system" workspace
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151875.html
>
>>The main reason why I don't think of it as SM is that SM
>>wants to be "all packages ever created for Squeak" but what we need is
>>"all packages that we've actually tested to work in this image"

Again, it _is_ just the tested packages exactly what we have on SqueakMap.

Hannes, please open a 4.2 image, and open up the SM catalog.  You
don't see 774 entries like you said before, you see exactly 22.  These
are the ones that have been tested to work in 4.2.

These will not "decay" because, the only way for them to carry forward
with the 4.3 entry is for someone to do the work of tagging it with
4.3 - which would only be done after they've tested it to load and
work under 4.3 legacy release.

Until then, the Catalog list will be BLANK in the 4.3 image.  Does
that make sense?

> It contains the "Community supported" packages, i.e. the ones which
> should work with the current image at hand.

NO, not the "current image at hand".  Only the image they are
_designated_ to work with.

> Note: 2
> BTW The main entry for Seaside on SqueakMap does not show that Seaside
> is as well in the Squeak4.2 category.

Ok, but don't go by the main entry, go by the individual version
entries - which is how the SM list is formulated in the image.  What
happened is, SM allows generic category selection, and people should
not select Squeak version type categories for the main entry - just
the category of software it is for (web, database, etc.).

> Maybe this is the reason that the Seaside entry only shows up in
> parenthesis in the SqueakMap loader?

Parenthesis means it has not been marked as "published" - which means
it my still change in the future.  Packages that are marked as
published are supposed to never change again.