Packages in both the image and SqueakMap (was Re: [FIX]
NoDoitInPackageInfo-nk ( Included in latest version of PackageInfo))
Doug Way
dway at riskmetrics.com
Wed Jul 9 16:03:43 UTC 2003
Daniel Vainsencher wrote:
>I think the criteria for when to update the in the image packages from
>SM should be when
>A. The author (or someone else) reports some significant change.
>B. And we've seen that it's stable enough.
>
>Can you elaborate on why you think we should update them before
>releases?
>
Well, I wouldn't say we should automatically update them all from SM
before a release. More that an upcoming release is a good checkpoint to
consider updating each one.
In this case, we just have SMLoader and PackageInfo which have newer
versions on SM. The latest SMLoader fixes at least one significant
problem (the slow menu), and seems pretty stable (I've been using it for
awhile, and I haven't seen any bug reports on the list about it).
PackageInfo I'm less sure about, but the package owner (Avi) seems to
think it's ready to go in, as do other knowledgable users (Ned). So,
I'm willing to add them based on this. (In theory we could wait a few
more days before incorporating the latest PackageInfo version, but it's
one of those situations where it will probably get much better testing
when it's in everyone's image.)
- Doug Way
>Daniel
>
>Doug Way <dway at riskmetrics.com> wrote:
>
>
>>On Monday, July 7, 2003, at 03:37 PM, Avi Bryant wrote:
>>
>>
>>
>>>On Mon, 7 Jul 2003 ned at bike-nomad.com 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
>>
>>
More information about the Squeak-dev
mailing list
|