iSqueak

[Bert Freudenberg]

That was one reason, the other major reason being that some tricky  
instance migrations are much easier to accomplish with a do-it. MC  
only really deals with code, not live objects. We have not tried to  
leverage the pre/post-load script mechanism, yet.

- Bert -

Am 18.06.2005 um 20:47 schrieb stéphane ducasse:

> Andreas mentioned that they coupled cs and packages since squeak  
> itself is not packaged.
> Just some packages and Tweak. but this is the way to go. So I would  
> go for #1
>
> Stef
>
> On 18 juin 05, at 19:23, Doug Way wrote:
>
>
>>
>> On Jun 18, 2005, at 12:44 PM, stéphane ducasse wrote:
>>
>>
>>>
>>> what we should fix is what do we do with the changes that are in  
>>> 3.9alpha stream.
>>> I also have some new changes/fixes on my disc ready to be added  
>>> to the stream.
>>>
>>>
>>
>> Assuming we go ahead with the iSqueak plan, there are two ways to  
>> handle this:
>>
>> 1.  Start with the iSqueak 3.8 image/packaging as-is.  Then re-add  
>> those 3.9alpha changes via the new Monticello process.  You might  
>> be able to just file-in all of the 3.9alpha changesets into the  
>> iSqueak 3.8 image, then commit all of the changed MC packages to  
>> our new release repository (which doesn't exist yet).  Right,  
>> Avi?  It only gets tricky if there are some order-dependent  
>> changes, or do-its, then you might have to post a Config Map/do-it  
>> update as Andreas was describing.
>>
>> Or,
>>
>> 2.  Start with our 3.9alpha image, and then re-do the iSqueak  
>> packagizing.  Might be doable, not sure.
>>
>> Although I guess you were talking about starting over at 3.8  
>> anyway, right?  So I think that means #2 doesn't make any sense,  
>> let's just do #1.
>>
>> - Doug
>>
>>
>>
>>
>
>