The root of the problem, that we don't have enough resources to maintain two different images: core and dev.
So we decided to keep only one release artifact since 1.4. It will be bigger than existing Pharo-Core, but i think smaller than older Pharo-Dev images. It is all about optimizing our workload, and to make sure that things we're releasing is working and well tested. Because in 1.2-1.3 we have issues with this separation (i think you aware of that). Concerning building vs carving: i agree, we should build rather than carving :) But testing that parts of image could be unloaded/thrown away is also useful. On 16 August 2011 20:21, Torsten Bergmann <[email protected]> wrote: > Stef/Mariano wrote: >>> So now we are including several packages in the image so that we do not >>> have two images. >>> >>> I am not against this, but I think it is a must to provide a >>> #shrinkToPharoCore and a hudson associated to that. >> >>yes good idea > > Interesting (nearly silent) switch in the way we build Pharo(core). > > > With one "Core" and several distro packages like "pharo-dev", "seaside" > we once switched to the model anyone is used to in other technology sectors: > building a house or a machine by stacking up/assembling small pieces. > So we had a "start with a base/core and load what you need" model > similar to Linux kernel and distros. So you could pick up what you need. > > I thought this is the right model - since we can cleanly load > and keep images small while checking if something is running > after loading with CI/Hudson. > > But now we extract the kernel/core from the (bloated?) distro. > > For whatever reason I often see this tradition of "Stone carving" in > Smalltalk. One has a large image and strips it down for deployment > (throw out what you do not need). Often you get problems in unloading/ > clean loading again. Classes are referenced across the image without > checking the load order, ... > > > Mmmmhhh ... who shares the same feeling that this is not a good idea! > When there is a #shrinkToPharoCore then there is a pharo core image > anyway - so we always have two images. And we have to test it and > check if packages load cleanly anyway (using CI). > > Can you at least ellaborate what led to this step? Is PharoKernel > the new Pharo Core? Will we test reloading after shrinking? ... > > Thx > T. > > > > > > > > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > -- Best regards, Igor Stasenko AKA sig.
