Replying to my own message...

After thinking about it some more, I think I like my idea about tweaking the
version filtering in the Package Loader (SMLoader).

Specifically, we would change the filtering so that a package listed as being
"Squeak3.4" compatible would show up in the filtered Package Loader if we are
running a 3.5alpha image, as well as a 3.4alpha/beta/gamma/final image.  (Not
3.5beta or any later versions, though.)

This gives us some leeway so that the Package Loader isn't suddenly empty as
it is now with 3.5alpha, which looks like a bug as Ken mentions below.  We're
just postponing the decision for package owners ("is my package really
3.5-compatible?") until Squeak reaches a beta stage, which I think is a better
time to decide.  Sometime during the evolution of 3.5alpha, a package listed
as 3.4-compatible may suddenly stop working.  But this is okay... alpha image
users are basically test pilots, and package compatibility can't really be
guaranteed during an alpha phase anyway.  However, we'd like people using
3.5final to be sure that a 3.5-compatible package really does work there. 
(unless the package maintainer is lying ;-) )

This becomes somewhat less important once the image is broken down into
packages, and we get package dependencies going.  But I think this would be a
good tweak to make for now.

Just looking for further feedback on whether this is actually a good idea.

- Doug Way


Doug Way wrote:
> 
> On Thursday, February 6, 2003, at 06:53 PM, Ned Konz wrote:
> 
> > On Thursday 06 February 2003 03:20 pm, Ken G. Brown wrote:
> >> (using 3.5alpha) I tried downloading after the first
> >> select of Connectors 1.9, then tried again after deselecting and
> >> selecting again without changing the checkboxes in between. Still
> >> no go, no .SAR. Here's the Transcript of the Install and attempt to
> >> download.
> >
> > OK, I just tried this.
> >
> > I had to load the "SARInstaller for 3.4" package first manually before
> > downloading/installing Connectors would work.
> >
> > It appears that we need to address these SqueakMap problems:
> >
> > * many packages that are 3.4 compatible are also 3.5a compatible (and
> > should be marked as such?)
> 
> Hm, this same issue came up when 3.4alpha was created from 3.2, and all
> of the packages in SqueakMap at that point were only listed as being
> compatible with 3.2.  Eventually, the package maintainers updated their
> packages to also be compatible with 3.4 (assuming the packages were
> indeed compatible with 3.4).
> 
> The general problem here is that at this moment, the 3.4gamma and
> 3.5alpha images are pretty much identical, so for now all
> 3.4-compatible packages are also 3.5(alpha)-compatible, and so a lot of
> package maintainers will probably just add "3.5" compatibility to their
> package.  But then 3.5alpha will be undergoing lots of changes over the
> next few months, and some packages will become incompatible.  I'm not
> sure there's a perfect solution to this problem.  (Well, long-term, the
> image will be split up into packages/modules which will rely on a
> separate dependencies mechanism and the image-compatibility thing won't
> matter that much.  But that's still a ways off.)
> 
> Maybe one solution would be to show immediately previous version
> packages while the image is alpha, but when it switches to beta, stop
> showing them.  For example, 3.4-compatible packages would show up in
> SMLoader if you're using 3.5alpha, but not for 3.5beta.  This would
> force maintainers to decide whether their package really worked with
> the beta/final image, since the beta image would be pretty close in
> functionality to the final image.  Eh, that's not a perfect solution
> either, but it's something. :-)
> 
> (Side issue: Goran needs to add "Squeak3.5" to the list of available
> versions on SqueakMap.)
> 
> > * The approprate installer packages should be loaded when SqueakMap is
> > loaded. Perhaps the load is also being confused by the version
> > number.
> 
> This definitely sounds like a bug/problem which should be fixed.
> 
> - Doug Way