Daniel Vainsencher <danielv at netvision.net.il> wrote:
> As far the SMLoader behavior - as agreed before, I changed the filtering
> so that any package that has a category that is a prefix of the current
> Smalltalk version will be displayed.

Good for now. If you want to you could instead make the menu choice read
"filter on version..." and in a submenu list one checkbox menuitem for
each of the subcategories of category "Squeak version".

That would give you:
- Possibility to filter for both 3.2 and 3.4 or some other combination.
- The menu will dynamically change together with the categories in SM.
So when 3.5 is added it will turn up there as an item.
- The possibility of actually showing all 3.4alpha packages even though
you are running a 3.2 image.
- Then you could (if you like) show at the top of this submenu the
current version as "Current image version: 3.2.1" and that would give
the use enough info to know what to pick.

> Since right now the packages are tagged as 3.4alpha, we'll lose them
> all. I don't think we really care about that level of resolution, and
> should move the packages to 3.2/3.4/.. style categories.

I agree and I can rename the categories whenever we like - they are not
referenced by name.

> This shouldn't come up as an issue everytime we consider changing our
> version status.

Right, see above proposal. And if you intend to implement it - refer to
the category "Squeak version" by id - that will not change. (I know it
feels awkward to code like that but I can't think of any better way)


Now, to something completely different (The Larch)- what IS Squeak
today?

The reason I ask is that I would like us to reconsider what it means to
move 3.4alpha over to beta.
Scott and Ned have been pointing out problems (all correct btw) in
SMLoader/SqueakMap that should be fixed before we go to beta - but beta
of what? Both these packages are not in the base image!

I agree that many users will consider them to be, but the question is
still valid - what is Squeak? Just the base image? Or the base +
SqueakMap + SM Package Loader? etc.

Just mentioning this - the packages live their own life now. But we can
of course select some packages as "base images" that should follow some
sort of release scheme in synch with the image etc.

Need to read up a bit on how Debian does this.

Btw, if Ned or someone does a bit of job on fixing the error reporting
for download/install then just send me a cs and I will integrate for
1.05. Don't do too much work though - I am working on changing that
structure into a service model.

regards, Göran