Hi Doug. <back on-list>

Yes, well, I've never quite left the list, but I've been preoccupied for
a while now, and I haven't quite resurfaced yet, but a bit... :-)

We've had a very similar when 3.4 was created. Then I resisted having
any of the tweaks that were mentioned, because I felt the added
complexity without solving a problem. 

The policy you present in your post does make some sense - people should
review compatibility when things start stabling down, not when a new
version is named. It's not perfect, because it still adds complexity -
less people will understand what is happening - when their packages
appear and when not.

But that's a matter of naming - your solution makes the activities
right. Maybe some changed naming or documentation would make this
clearer.

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?

Again this might require a little more formalizing the concept, or
maintaining a "previous-to" list somewhere (could be in some package,
BTW).

Assuming other people don't object, I'll accept a patch to SMLoader that
deals with all of this.

Daniel

Doug Way <dway at riskmetrics.com> wrote:
> 
> Hi Daniel, I noticed you just popped up on squeak-dev again :-), so I thought
> I'd ask what you thought of my suggested tweak to SMLoader here.
> 
> - Doug
> 
> 
> -------- Original Message --------
> Subject: Package Loader version filtering (was Re: [BUG]SqueakMap
> 3.5aproblems)
> Date: Fri, 07 Feb 2003 20:03:50 -0500
> From: Doug Way <dway at riskmetrics.com>
> Reply-To: The general-purpose Squeak developers
> list<squeak-dev at lists.squeakfoundation.org>
> To: The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> References: <E04F4347-3A58-11D7-A2CB-00306558B8E0 at riskmetrics.com>
> 
> 
> 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