Thanks for quick your answer, Goran! See my comments below.

goran.krampe at bluefish.se wrote:
> > Note that I am aware that installPackageNamed: should not be used any
> > more. Is there a protocol which does exactly the same as the Package
> > Loader if I click yes twice? The methods
> > #installPackageLatestPublishedNamed: and
> > #installPackageNamed:autoVersion: seem to do slightly different things.
> 
> "Yes twice" ought to mean that you want to install the latest release
> regardless of the current image version or if it is not published. That
> is not advisable to have in a load script since it will disable both
> those mechanisms and cause unexpected problems for the user.
What I want to live wild and dangerous? ;-)

> Note that I am aware that there are quite a few methods for installation
> now and some overlap etc, I need to make this clearer. Anyway, my advice
> is to either specify a specific release like this:
> 
> SMSqueakMap default installPackageNamed: 'Worlds Of Squeak Removal'
> autoVersion: '1'
That is what I use currently.

(Just fyi, it took me several tries until I figured out what was meant
with autoVersion. First, I tried '2', then 2, then 'r1'. Then I almost
concluded the method was broken. Only then I had the idea to try out
'1'.)

> Since we are pointing at a specific release this will "bypass" the
> checks if it is in fact published/not published or marked for the Squeak
> version that the user has.
> 
> The other method you mention, #installPackageLatestPublishedNamed: and
> it's sister method #installPackageLatestPublished: should IMHO probably
> be removed. They don't check the Squeak version and probably only
> confuse things.
> 
> Ok, if you don't want to specify a specific release - then the
> installPackageNamed: would work *iff* there was a published release of
> "Worlds Of Squeak Removal" that also was marked for Squeak 3.7.
Well, this illustrates the problem with approaches like this: When a new
release is made all packages are automatically shown as "dangerous" to
the user even if they work fine. In a way, you get hundreds of false
positives and need manual intervention of a developer to remove them
again. And this even for ultra stable packages which were not touched
since a long time.

That leads me to the following conclusions: If a package is not marked
as 3.7 chances are high that it works anyway. OTOH, even if a package is
marked as 3.7 it does not guarantee that it will work, because chances
are high that there are conflicts with other packages marked as 3.7.
Therefore I pretty much ignore this category completely.

Thinking about it, I'd find it interesting to try out the opposite
approach: to list only information of the following kind: Package A
Version 1 is known to have a conflict with Package B Version 3. I can
imagine that this would be much less information and thus much easier to
maintain. It would be necessary that this information can be supplied by
anyone, not only the package developers.

> So given the two "safety mechanisms" we have now - the check for
> published, and the check for correct Squeak version - the
> install-methods that do not specify a specific release are much more
> "ok" to use.
With all respect, I disagree. To load the latest version of a package
regardless of the Squeak version I use seems a very common use case to
me. I would even dare to bet that most people will answer yes to both
questions in almost all cases.

Thanks again for looking into my problems and for your valuable
contributions to Squeak! SqueakMap is really great!

Bernhard