Hi Lex and all!

First - Lex - if you think I am missing anything in my replies, please
post again. I am getting slightly drowned right now. :)

lex at cc.gatech.edu wrote:
> > > 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.

Less common? Hardly. There are TONS of packages that work in 3.4, 3.5,
3.6, 3.7 etc.

And AFAIK merely a few that have been split up with different packages
for different versions - and do note that *that* isn't needed anymore.
SqueakMap handles this today. Yes, it does. Perhaps not perfectly, but
it does AFAIK.

> 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

No, I agree with that. What I *do not* agree with is that it would
somehow be better/simpler by having multiple maps. I have yet to see a
single convincing argument of that.

> 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

What do you mean? It is already implemented. Create a release and select
what versions of Squeak it works with. Then create another release and
select what versions it works with.

The thing that we don't have a UI for yet - but this might be a good
time to add it - is branches. The model handles them.

> maps results in a more pleasant system than what we have now, where
> people split their packages manually.  And there are other benefits in

No need to split anymore. The splits happened AFAIK before we added
support of releases.

> addition to a convenient way to have multiple versions per package, as I
> have described in other posts.

Not sure what those were.

> > 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?

Eh, I am not sure you are aware of what SM does today. Today it would
work perfectly well.
If we disregard the fact that the map contents aren't consistent with
the current features of the map - it handles it as it should.

Use the filters and select "new safely available" (in a 3.4 image). Note
that I haven't tried running current SM in 3.4 - not even sure it works.
:) That would show all package with a mark of "Squeak 3.4" on either the
package itself (implying all releases) or on at least one of its
releases - and which of at least one is published. Well, it is even a
bit more refined than that - see SMPackage>>isSafelyAvailable.

For some numbers here, there are 221 package with release(s) (or the
package itself) marked for 3.6. 178 for 3.7 and 89 for both. This both
tells me there are TONS of packages that are available for more than one
Squeak version and it also tells me that there are many maintainers that
have managed to put that 3.7-tag in place.

It seems to me your whole argument has missed the fact that we have
*releases* now.

> 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.

What is this? Why are you saying that this is easier than what we have
now (a part from the UI)?

First you say it is a nuisance to keep the tags up to date in the
current SM and then you say this? You totally lost me. There is no
difference at all. In fact - current SM is easier because you can test
the release in 2-3 different Squeak versions and then make the release
once and for all.

> 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 am sorry Lex, but this all works today. Open the package loader,
filter on "display only safely available". Done. The only thing I didn't
have time to add is to see which ones of the releases (of each package)
are actually "filtered out" - I elected to show them all at this time,
because hiding releases may be confusing. But it would be nice with a
visual cue to see which specific releases are "safe" for you.

But the listed packages should be the correct ones, and if you use
"install" on the package (and not a specific release) it should pick the
last release that is *published* and *for your Squeak version* first.
Then it tries to fail "nicely" and offer other choices. Sure, it can
surely be improved. 
 
> > 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.

So what if I want a stable KomHttpServer, but a bleeding edge Shout?
Then I will need to connect to multiple maps at the same time? Do you
have any idea how much more complex that would be compared to what we
have today? How would multiple maps share categories in a sound way? Or
information about maintainers? How would the dependency management work
later on?

And don't say "Debian" - I know how it works there - but SM is more than
that. It can already do more in many areas. (and less in others)

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

No, they aren't. On the contrary. Having a single domain model instead
of multiple is per definition easier. There is nothing stopping the
model to embrace all these mechanisms and this is what I am working to
do.
 
> 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.

Noone is saying "automatically". It is all about collecting information
in a coherent model. It is easier to collect this information in ONE
model.
  
> 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. 

There is NOTHING that prevents us from having the same in SM.
  
> -Lex

Lex, I am getting slightly tired of this discussion because it doesn't
seem to me you are even trying to look at how SM works.

I know docs are lacking, but the source is out there. Classes SMLoader,
SMPackage, SMPackageRelease are kinda simple to look at I think.

regards, Göran

PS. This just proves I really, really need to write that SM article...