Fun with Symbol

There are many differences between SM and PU.  One is the SM is
supposed to have everything in it, a "single stop shop", and PU is
only supposed to have things that work for a particular version, and
that presumably work together.    Of course, SM doesn't have
everything, and it is easy to put two packages in PU that do not work
together.  Reality is never quite up to our expectations.
Nevertheless, SM is more "universal" than PU, and a PU is more
coherent and the things in it are more likely to work together than
SM.

One way to solve this is to make SM more automatic.  It could be given
rules about where a particular package could be found and could update
itself automatically.  So, it could get its latest version from a MC
repository or from a PU.

Another way is to change PU so that when you update a PU, it
automatically updaes SM.

Personally, I prefer the PU model to the SM model, though it is
certainly useful to have a complete list of Squeak projects, even if
the projects are often out of date and won't run in my current image.
Most of the time I prefer to have software that I can assume works.

-Ralph

On May 29, 2007, at 14:00 , Philippe Marschall wrote:

> - Don't encode "Chronos versions" to Monticello filenames. Instead use
> an internal mapping for "Monticello versions" to "Chronos versions"
> and vice versa.

This is good advice.

However, if you insist on having "meaningful" version names it helps  
to know the conventions that tools like SqueakSource or the MC  
repository browser assume: "packagename-version" where "packagename"  
is the Monticello package name (including dashes) and version  
generally is "author.number" (should not contain a dash). The  
"author" is pretty much free-form, so you could put anything you like  
there without confusing the tools (which look for dots and dashes).

- Bert -