[Pharo-project] A radical proposal (to cut down dead code)

Tudor Girba tudor at tudorgirba.com
Sat May 28 17:32:24 CEST 2011


In Moose we do the same.

Moose builds on the latest stable Pharo, and we use this for daily development. We also use a manual update of the latest Pharo to control the deltas and understand their consequences.

We migrated from Pharo 1.2 to Pharo 1.3 in about an estimated of 10h of work including testing / deploying. This was mostly due to the radical but fantastic changes in Announcements :). From 1.1 to 1.2 it was even less.

So, although lots of things change behind the Pharo hood, the overall compatibility is quite high. And Moose stresses the system. So, I would not overestimate the effort of migrating.


On 28 May 2011, at 17:06, Yanni Chiu wrote:

> On 28/05/11 10:16 AM, Stefan Marr wrote:
>> Hi Marcus:
>> On 28 May 2011, at 15:35, Marcus Denker wrote:
>>> There is *a lot* of dead code in the image.
>>> This way we can, within 2-3 interations, remove *a lot* of dead code.
>> Which tools do you imagine to allow your users to keep up with the pace of the changes of system?
> I use two automated builds. One stream builds on fixed versions of PharoCore + other stuff. I use this for day-to-day development.
> The other stream builds my stuff on the latest PharoCore. I manually update to the latest, so there is some lag, but I still find out fairly soon, when a change has affected my stuff.
> If something is broken, then I would try to make my stuff work in both streams. If that looks like a bad approach, then I could lobby for a change/undo of whatever broke my stuff - while active development of that Pharo version is still ongoing.
> That's the theory. My build has been broken for 10 days now. That's a matter of hours available and priorities, but I think the process is sound.


"Value is always contextual."

More information about the Pharo-project mailing list