The future of SM...

Chris Muller afunkyobject at yahoo.com
Mon Jul 19 18:10:18 UTC 2004


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

> ...
> 3. Number two is, as you suggest, to have dependencies between packages.
> They do not need to be complex as we get going, but please do make them
> based on packages not particular versions.  At the distribution level,
> the dependencies should be like "Scamper needs URL", not "Scamper 1.5
> needs URL 1.3".  This is because, within a distribution, users almost
> always want to have the newest versions of the packages.

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.

But what you said is also needed.  For a developer/configurator ready to move
forward with newer versions of packages, loading a configuration requiring an
older version of a required package shouldn't replace the newer one without
permission.  The point being, the choice of what to do should be decided by the
configurator (person), not the (SM) software.

Regards,
  Chris



More information about the Squeak-dev mailing list