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
>>>
>>>
>>>
>>
>>
>>
>>
> 
> 
>