Fwd: Packages in both the image and SqueakMap (was Re: [FIX] NoDoitInPackageInfo-nk ( Included in latest version ofPackageInfo))

FYI, if no one objects, I will update the SM packages that are in the 
image, by adding the latest versions to the update stream.  Only the 
SMPackageLoader and PackageInfo have newer versions on SM, so these are 
the only two that will get updated.  The version on SM is still the 
"master", as described below.  (Seems relatively safe, since there 
haven't been big changes to either of these and they've been publicly 
available for awhile.)  This will be the last update of this sort for 
3.6.

I'll do this sometime tomorrow, and I'll incorporate the latest 
approved items while I'm at it.

- Doug


Begin forwarded message:

> From: Doug Way <[email protected]>
> Date: Tue Jul 8, 2003  1:21:18 AM America/Detroit
> To: The general-purpose Squeak developers list 
> <[email protected]>
> Subject: Packages in both the image and SqueakMap (was Re: [FIX] 
> NoDoitInPackageInfo-nk (  Included in latest version of PackageInfo))
> Reply-To: The general-purpose Squeak developers list 
> <[email protected]>
>
>
> On Monday, July 7, 2003, at 03:37 PM, Avi Bryant wrote:
>
>> On Mon, 7 Jul 2003 [email protected] wrote:
>>
>>> I notice that this has been included in the latest version of
>>> PackageInfo from SqueakMap. ...
>>> Shouldn't we post the latest version (or a change set with the 
>>> deltas)
>>> to the update stream, now that PackageInfo is in the base?
>>
>> I'm unclear on the policy here.  I thought maybe SM, PackageInfo etc 
>> were
>> meant to be one time inclusions in the update stream, which would be
>> updated through SM from then on.  Doug?
>
> I've been wondering about this myself.  The general idea was that the 
> version on SM would be the primary/official one which would be updated 
> regularly.
>
> But practically speaking, we don't want the one in the image to become 
> out of date enough that it's completely broken.  It's a bit of a mess, 
> actually, having them in both places. :-)  But it's really a 
> short-term solution until SM 1.1 is ready and a dependency scheme 
> comes together... so we shouldn't have to deal with this for *too* 
> long.
>
> Anyway, probably what we should do is still treat the code on SM as 
> the official versions, but update the ones in the image every once in 
> a while from SM, if things start becoming incompatible.  (And perhaps 
> they should be updated before releases, too, which means we might want 
> to update them right now... assuming the changes are not too large.)
>
> - Doug Way
>