Update stream vs. SM packages (was: RE: [ANN] Squeak 3.5released)

Brian Brown rbb at techgame.net
Mon Apr 14 16:24:32 UTC 2003

On Monday 14 April 2003 10:52 am, Andreas Raab wrote:
> Brian,
> > I see SM as a system containing Community contributed
> > software, where the individual maintainers post new updates
> > to those discrete packages, and I as a user can choose
> > whether to update a particular package or not.
> Yes. And wouldn't it be appropriate to have the same ability when you want
> to update your system to the next version?

Sure... it's really a "semantic" difference, if you'll allow me to abuse the 
word. Of course I want to update, or not update, my system to the next 
version... I guess what I'm getting at is that there are currently two ways 
to update things... one from the World menu, and one from SM (ignore the fact 
that changesets abound :)

> > I see the update stream as dealing with "Core" Squeak code,
> > bug fixes, enhancements, etc, as fundamentally different the SM
> Fundamentally different? Where? Both are mechanisms for distributing code
> and whether a package contains a self-contained set of changes or not is
> really up to the maintainer. For example, SmaCC requires the RB parse
> nodes, Jacaranda requires Connectors. Where's the difference?
Especially considering that this is a living object system, there is no 
fundamental difference... it's a difference (IMHO) in trustworthyness... I 
don't expect a bugfix release of the core squeak image to break other core 
squeak things in my image... if I load a package from SM I accept that I may 
have to roll it back (Zurgle for example, hosed Morphic for me, so I just 
rolled it back)

> > I understand this line of reasoning, but I think this will
> > lead to confusion on the part of users, especially new users...
> Most of the confusion of new users come from obscure UIs...
Agreed, and a very good point as well.

> > and when the dependency code is part of the mainstream SM,
> > and I want to load Jacaranda, then it will load
> > Ned's connectors and possibly.... say, bug fixes to Squeak,
> > so it revs it 3.5.3 or something?
> If you're okay with pulling in Connectors why is it so problematic to you
> to pull in a version update? In both cases you get "more than you want" and
> I would claim that in both cases you should therefore get an information
> about what is going on. For example:
> Jacaranda vX.Y requires the following packages to be present:
> 	* Connector (vX.Y)
> 	* SqueakUpdate (vX.Y)
> Do you want to load these?
> The system tells you what it is going to do and it's at your disposal to
> take it or leave it. To me, that's clearly an advantage about not being
> able to load Jacaranda at all, don't you think?
I don't disagree with these points... I just think we should unify the updates 
into one interface or split out bugfixes into "Load code updates" and whole 
packages into squeakmap.

Right now, there is also the SM menu choice to "upgrade all installed 
packages" - Scary, to say the least; but as you pointed out, that is a UI 

> > I would like to see (at least I think I would at this
> > point).. putting *all* bugfix type updated into the
> > update stream... so if Magma has a bugfix posted
> > to it, when I choose "Get code updates" from the World menu,
> > it not only fixes my core Squeak bugs, but any installed
> > packages I have as well (but not upgrading packages to new
> > versions!)
> But that's entirely unrelated to what I was saying. One is the issue of
> hosting Squeak version updates at SquakMap (which I was talking about) and
> the other is the ability to have update streams for each package (what you
> are talking about).

Yeah, you're right... I was bringing more into it... cuz I think they are 
related ;)

> Cheers,
>   - Andreas

Bis Spater,


More information about the Squeak-dev mailing list