On Monday, February 10, 2003, at 03:47 PM, Daniel Vainsencher wrote:

> ...
> We had a very similar issue 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.

Right, it does add a bit of complexity to the rules, though not a lot, 
so it's not a perfect solution.   But I think it does improve the 
situation overall by having compatibility reviewed at a better time.

> 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. :-)

A slightly better solution might be to somehow get the ordered list of 
versions from SqueakMap, which appear in the correct order.  However,  
I guess this is still problematic, since 3.3alpha appears but is not 
really the predecessor to 3.4.

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

Yeah, I guess we would probably need something like this.

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

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)

- Doug Way


>
> Doug Way <dway at riskmetrics.com> wrote:
>>
>> -------- 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