Anybody want to help us Guides fix a process bug? (was: Re: [Fwd: Package Loader version filtering ...

Daniel Vainsencher danielv at
Wed Feb 12 15:06:58 UTC 2003

To summarize - 
As we've seen, every time we get a new alpha out the door, it has zero
packages. This is because it is suddenly not prefix compatible with it's
predecessor (3.5alpha does not being with the 3.4 tag), and so SMLoader
doesn't pass all those nice package through it's filter.

Which is pretty dumb, since the last gamma of 3.4 and the first alpha
are, actually, precisely equivalent - we don't make big changes in

As Doug says, the right time to be reviewing whether packages are still
compatible with a version is probably when a version enters beta (all
the big changes are already in, now it's time to see what is broken and
fix it).

So what we need is this - a patch to SMLoader such that it accepts all
packages for it's own version, and, if it's own version ends with
'alpha', also all package for the previous version. Where previous
version should correctly handle nonobvious cases like 4.0. One approach
is to store a list of "X's previous version was - Y". Another angle
might be a patch to Squeak that remembers what it's previous version
was, though I'm not sure that should be in the base image.

Doug Way <dway at> wrote: 
> On Monday, February 10, 2003, at 03:47 PM, Daniel Vainsencher wrote:
> > As far as implementation goes, it might be a little tricky to define
> > what versions should be considered acceptable. Do I show a version 3.2
> > package if I'm 3.4alpha? if I'm 4.0alpha?
> Oof, for some reason I didn't think about this.  Yes, simply 
> subtracting 0.1 from the version is quite likely to break for some 
> releases. :-)
This reminds me of a pattern, Selfish Classes, that describes what a
class needs to do to succeed, including subversive things like being so
huge and scary that nobody will even think of changing it unless they
really know what they're doing... 

Well, it's in the nature of a Selfish Hack to stretch it's own power up
until it reaches various not-quite-obvious limits that will then trip up
anyone trying to mess with it ;-)

> Hm, this task has become just barely large enough (w/having to deal 
> with the "previous-to" list) that I probably won't have time to work on 
> it for awhile.  If anyone else would like to implement it in the short 
> term, that would be great.  (it shouldn't be *that* difficult, actually)


More information about the Squeak-dev mailing list