On Mon, Apr 4, 2011 at 5:19 PM, Marcus Denker
<marcus.denker@inria.fr> wrote:
On Apr 4, 2011, at 5:05 PM, Mariano Martinez Peck wrote:
So....here is the list of things I guess are pending:
In general, for all pending things adding entries in the bug tracker is the only way ti make sure they are not forgotten.
1) "Release" all configurations included in Pharo (this is, ConfigurationOfPharo and all it dependencies). I mean, we should NOT use or depend on #development versions.
so...can someone check this is done?� GUillermo and me did it once...but it seems a lot of stuff was updated once again
I just gave up and took the image yesterday. Like you did for 1.1: Just build it once, don't care that it is repeatable.
Sorry, I didn't understand. The Pharo 1.1 was repeatable (in the same core) since all the Metacello versions were frozen.
�
�
2) Update the one click image to use latest cog images and "pharo prepared vms". There are some issues regarding this...
Marcus, which is the status of this one ?
I updated the one-click image with the last cog VM.�
For the one-click, it is identical to 1.1 with the only change that I put the windows VM I got from�Torsten.
But 1.1 was not-Cog� (Cog 1.1.1 was cog). So...we are shipping the Pharo One Click 1.2� with the Interpreter VM instead of Cog ?
or did you mean 1.1.1 ?� if so, it would be good to update to latest Cog. The cog version used for 1.1.1 had several problems (I think the run:with:in: crashes the image -> TestCoverage)
�
3) Write down all the things/summary done in Pharo 1.2
consider as done in nobody else comes with something better,
�
5) Update� SystemVersion current -->> Pharo1.2rc2 of 27 January 2011 update 12340
SystemVersion current ->> Pharo1.2.1 of 2 April 2011 update 12345
so..it is ok, isn't it ? can we forget this item ?
�
6) Condense sources? condense changes?� #cleanUpForRelease
Marcus, is that necessary ?
DEVImageCreator >> cleanUps
���
��� ScriptLoader new cleanUpForRelease.
��� "In Pharo 1.1 condenseChanges is VERY slow because of the new method trailers. So condensingChanges each time even when it is not needed is not a good idea anymore. So in case a condenseChanges is needed it should be done explicitly.
��� Smalltalk condenseChanges."
��� Smalltalk garbageCollect.
�
I did that and I put that comment. Now that they are faster and that we have Hudson, should I put back the Smalltalk condenseChanges ?��� is there anything else needed?� do we need a condenseSources ?
CondenseChange and CondenseSource is broken right now.
Ok, we can live withoput that :)
�