> > 2. My number one desire, which is not on your list, is to stop talking
> > about "the" map.  At the very least, there should be a map per version
> > of Squeak, because in practice packages in Squeak 3.6 are not going to
> > work in Squeak 3.0 unless you make at least a few changes.
> 
> I think there are/will-continue-to-be plenty of packages that would work across
> multiple versions of Squeak.  Any "independent" package that does not depend
> highly on the volatile-guts of Squeak.. a Chess engine, for example.

I didn't say you couldn't post a package to multiple maps.  I expect
that it will be less common than you seem to think -- for example, the
changes to #new caused a *lot* of legacy code to break -- but whatever
the ration ends up being, there are definitely packages already that
want different versions in different versions of Squeak.

I have deleted 50-odd lines of commentary about this; if you really
disagree that we do frequently want different versions of a package in
different versions of Squeak, I'll edit it and post it for your
consideration.  Assuming that we agree that we sometimes want to have different
versions of the packages for different versions of Squeak, we must come
up with some way to implement it.  It seems to me that having separate
maps results in a more pleasant system than what we have now, where
people split their packages manually.  And there are other benefits in
addition to a convenient way to have multiple versions per package, as I
have described in other posts.


> I don't have anything against having another map, but I do like being able to
> go to ONE map for everything I need, no matter what version of Squeak I need it
> for.

Your goal and your strategy are inconsistent.  Today, we have a single
map, and yet you cannot simply go to SqueakMap and see what packages
work with the version of Squeak you are currently running.  There are
version tags there, but the tags are incorrect.  Keeping the tags up to
date is a real nuisance!  Imagine a Squeak user of today loading Squeak
3.4 and then opening the Package Loader.  How many of the packages they
see are going to actually work when they install them?

On the other hand, multiple maps make your goal easy.  The equivalent of
the version tags would be kept up to date in the normal course of
operation.  Consider.  Before you post a new version of a package, you
will do at least some minimal amount of testing in each image, such as
loading the program and seeing that it starts okay.  Once you are done
testing in each image, you'll open the Package Poster and press the
"POST IT" button.  Which map do you think it will post it to...?  It will post
it to the map that corresponds to the image you just tested in, surely.

Now picture what other users are going to see when they open up the
Package Browser in any particular image....  they are going to see a map
containing the most recent version of each package that has been tested
in the image version they are using.  If you did your testing in 3.6 and
they are in 3.4, then they will simply and automatically see the last
version you *did* test in 3.4.  It all works so simply and smoothly that
I daresay people won't think much about it at all, and they'd wonder
what all the fuss was about if they were to read these threads!


> I think it depends on the person.  Some people almost-always just want the
> latest-known "working configuration," even if that means they do not have the
> latest-and-greatest of every particular required package.  For example, if you
> have a dedicated computer to perform a menial chore and you don't need or care
> about having the latest, you just want the computer to do the work reliably
> (i.e., capture weather data, for example).
> 
> In this case, it's useful to be able to do a one-click install and KNOW that
> the entire configuration will work without having to debug or wonder if there's
> some change in one of the newer-versions of one of the sub-packages that is
> going to render it buggy.

In the extreme case, you won't update that computer at all, in which
case all of this discussion is moot.

If you do occasionally update it, however, you will typically want to
grab all of the bug fix updates that are out there, while avoiding any
updates that add new features.  Multiple maps solves this beautifully. 
Simply have a different updating policy for each map.  A map for Squeak
3.6 would only allow updates that have been thoroughly tested and which
do no more than fix bugs.  End of story.

With single maps, things are more complicated....


By the way, you used the word "know" very quickly.  Not only is a lack
of errors impossible to accomplish, but people who want to try hard to
achieve it are surely not going to want to rely only on random testers
from out on the Internet.  If you really want a super-stable Squeak
image, then you are going to have to test it yourself, in a specific
configuration.  Even if someone out on the net tested that exact same
set of package versions, you still would not want to automatically use
that configuration.  You would want to test it yourself.


Also by the way, the approach I described is exactly what Debian does,
and it seems to work well.  Debian is an excellent choice of Linux
distribution for high-reliability situations, precisely because it does
have separate streams of packages for "stable" and "unstable" systems. 


-Lex