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