[Pharo-project] Let's get rid of Core vs. Full
st-lists at stuartherring.com
Mon Apr 4 11:26:54 CEST 2011
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