[etoys-dev] Packaging Etoys

[Karl Ramberg]

Bert Freudenberg skrev 2010-03-01 18:23:
> It's a non-issue for us. We just need to re-categorize everything before creating the first "real" Monticello packages. That was the original plan anyway, not sure what the issue at hand is?
>
> - Bert -
>    

I guess we get a problem if run update stream and refer to methods in 
now changed categories. It would be nice to detect those on fileIn and 
put them where they should be.

Karl

> On 01.03.2010, at 17:52, karl ramberg wrote:
>    
>> Thank you for the answers.
>> Makes sends once I think about it. So we get bitten by early binding
>> of method categories...
>> This would be nice to choose on fileIn, so you just specify which
>> category / package a method should be in instead of
>> just applying the one in the change set...
>>
>> It would be nice to be able to use both change sets and Monticello for
>> a while until development gets traction and since most development in
>> Etoys have deep roots in change sets.
>>
>> Karl
>>
>>
>> On Mon, Mar 1, 2010 at 2:24 PM, David T. Lewis<lewis at mail.msen.com>  wrote:
>>      
>>> On Mon, Mar 01, 2010 at 11:06:45AM +0100, karl ramberg wrote:
>>>        
>>>> Hi.
>>>> Good work :-)
>>>>
>>>> Underscores should be fixed even though I prefer the arrow :-)
>>>>
>>>> How do I fix the second issue with package categories? I'm not really
>>>> used to Monticello so I fumble here.
>>>>          
>>> Hi Karl,
>>>
>>> This is something that Monticello does not handle well, and I am
>>> not sure if you will want to "fix" it or not. It is probably best
>>> to think about it for a couple of days, and also ask Bert what he
>>> thinks. Changing categories in the Etoys image will make it easier
>>> to compare Etoys with Squeak trunk, but it may cause other problems
>>> if patches are being tracked and applied through change sets.
>>>
>>> It is difficult (but not impossible) to make changes to the Squeak
>>> trunk package names, because it affects lots of people using the
>>> update stream, and because it makes the change history hard to
>>> track (due to Monticello). So realistically it means you need to
>>> decide if you want to change the categories in the Etoys image.
>>>
>>> Actually changing the categories is simple. If you change the
>>> category of a class (in a browser, in the usual way), Monticello
>>> will automatically treat it as belonging to a different category.
>>> Likewise, for method categories, changing the category from e.g.
>>> "foo" to "*Etoys-foo" moves it into the Etoys package. If you
>>> change the category of a class from "Foo" to "Bar", then you will
>>> need to save both the "Foo" and "Bar" packages in Monticello.
>>> The class will disappear from the Foo package, and appear as
>>> new in the Bar package.
>>>
>>> One note concerning the Etoys package naming - Monticello does
>>> not seem to care about upper/lower case names, so from my
>>> Monticello browser in a Squeak trunk image, the "Etoys" package
>>> in source.squeak.org/etoys appears in package "EToys" in my
>>> browser. The archive files in source.squeak.org/trunk have names
>>> like "EToys-dtl.62", and the archive files in source.squeak.org/etoys
>>> have names like "Etoys-kfr.3" (lower-case $t). As far as I can
>>> tell, this is harmless but maybe a bit confusing.
>>>
>>>
>>>
>>> Dave
>>>
>>>
>>>        
>> _______________________________________________
>> etoys-dev mailing list
>> etoys-dev at squeakland.org
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>>      
>
>
>
>