Important for 3.9 submissions and fixes
Daniel Vainsencher
daniel.vainsencher at gmail.com
Sat Sep 10 19:19:34 UTC 2005
I think that the solution is counter intuitive but simple. When moving
things from Morphic to EToys, with M.1, E.1 being the initial versions,
you need to publish M.2, E.2 with M.2 depending on E.2, so that E.2 (the
version that already has the stuff) is loaded before M.2 (the version
that's missing the stuff).
So the dependencies seem inverse, but if you think about them as just a
way to order loading, rather than as a way to specify what packages need
what other packages, it makes sense. And this can be changed in the next
release of the packages.
Daniel
stéphane ducasse wrote:
>
> On 10 sept. 05, at 19:30, Juan Vuletich wrote:
>
>
>> Hi Stef,
>>
>> What follows is copy/pasted from another mail I've just sent, but
>> what I say also aplies to this discussion. The point is that when
>> submitting stuff to be harvested, I believe sometimes changeSets are
>> better than MC.
>>
>> Now I see that the packages in the last published image should be the
>> last
>> ones published in source.squeakfoundation.org.
>>
>
> No marcus will certainly publish a new image but you can get the newest
> changes
> by loading manually the most recent versions of the package from the
> source.squeakfoundation.org repository.
>
>
>
>> I see two ways of keeping that consistency.
>>
>> a) If someone publishes stuff in a .cs. Then you file that in in the
>> master
>> image, and then save new versions of the modified packages, and
>> publish the
>> new master image.
>>
>> b) Someone publishes stuff in a MC package in
>> source.squeakfoundation.org.
>> Then you load the new packages in the master image and publish it.
>>
>> For this first MorphicSplitters work, option a) is the only choice.
>> If we
>> try option b), well have a problem we had several months ago in the
>> MorphicSplitters group, when using Cees' repository.
>>
>
> I understand.
>
>
>> Let's suppose I (Juan) file in the MorphicSplitters cs, and publish the
>> resulting packages. Basically what we did is to move stuff out of the
>> Morphic package and in the MorphicExtras and EToys package.
>>
>> When you (Stef) try to load those packages in the master image,
>> because of
>> the prerequisites, you will load Morphic first, then MorphicExtras
>> and then
>> EToys. When you load Morphic, MC removes all the classes that were in
>> Morphic before and now will be loaded in MorphicExtras or EToys. But
>> when
>> they are loaded back in the new package, all live instances and class
>> variables are lost.
>>
>> This problem only occurs when moving stuff, modifying package
>> boundaries,
>> not when updating a package.
>>
>> So, when setting package boundaries, it's better to do it via change
>> sets.
>>
>
> Ok we will learn by doing it.
>
> Stef
>
>>
>> Cheers,
>> Juan
>>
>> ----- Original Message ----- From: "stéphane ducasse"
>> <ducasse at iam.unibe.ch>
>> To: "The general-purpose Squeak developers list" <squeak-
>> dev at lists.squeakfoundation.org>
>> Sent: Saturday, September 10, 2005 5:42 AM
>> Subject: Important for 3.9 submissions and fixes
>>
>>
>>
>>
>>> Hi all
>>>
>>> To ease harvesting I would like that we follow the following rules:
>>> - check that if you removed a method, you deprecated it,
>>> - check all its callers
>>>
>>> - if your changes only affect a package, publish it in that
>>> package on inbox
>>> - if your changes cross cut several packages, then package them
>>> as another
>>> package and during the inclusion in the image we will take care to
>>> dispatch the changes atomically in the right packages. Else
>>> this will be the hell
>>> for me to know which packages version should be loaded with each
>>> other one
>>> - add clear comments and dependencies if any between the changes!!!
>>>
>>> I'm sure that you understand my points
>>>
>>> Stef
>>>
>>>
>>>
>>> --
>>> Internal Virus Database is out-of-date.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date:
>>> 8/26/2005
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
More information about the Squeak-dev
mailing list
|