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

goran.krampe@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