[Pharo-project] Let's get rid of Core vs. Full
estebanlm at gmail.com
Mon Apr 4 15:30:08 CEST 2011
Well... I disagree to completely abandon full images.
I understand the good reasons Marcus et all have to propose this, but in my opinion abandon a development image with needed development tools is a mistake, because most of us use it for development our applications, and most of newbies for sure need it, and don't know how to build it by themselves.
Most of my students use the Pharo full image, and they tend to consider full images the real "Pharo" images (same way most people consider JSE version of eclipse the "real" eclipse).
Said so... I really thing we need to flatten the pharo full image to it's minimal expression. I think now is some-kind over bloated and most of the problems we have is because we add too much packages to it, and for that reason we can't use it to develop the core image.
My proposition for 1.3:
1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea)
2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser
3) If it is possible, develop Core image into this reduced full image.
El 04/04/2011, a las 6:26a.m., Stuart Herring escribió:
> On Mon, Apr 4, 2011 at 3:56 AM, Dale Henrichs <dhenrich at vmware.com> wrote:
>> Rather than abandon core vs full, here's a thought on a slightly different approach...
>> Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ...
>> Use the build server to run tests against the CORE and the set of CORE tools...
> This is what makes the most sense to me as a user - and one that uses
> both core and dev.
> Dev is what I spend 99% of my time in, and of course core is what I
> actually deploy my applications on. But pretty much all of my
> impression of Pharo comes from Dev.
> The worry I would have about having only core releases, or core +
> untested Dev script would be that given the "clean design over
> backward compatibility" philosophy, none of the development tools
> would ever keep up with the changes in Core. You'd effectively have a
> product that was unusable to a developer (or at least, not a fair
> representation of how good Smalltalk can be for development).
> It basically comes down to this:
> Either you want to provide developer tools with Pharo or you do not.
> If you do not, then ditch Dev entirely, and make it very clear that
> Pharo is just a platform, and the third party developers of
> development tools will need to support Pharo specifically.
> If you do, then the Development tools need to be first class citizens.
> You need to develop in Dev - which is built from Core. And Dev needs
> to benefit from the same sorts of refactorings and cleanings as Core
> does, and tests in Dev must always be green (blue).
> Given that the webpage currently states that providing excellent
> development tools is a primary goal of Pharo, I feel that Dale's
> approach is what makes the most sense.
More information about the Pharo-project