On Mon, Apr 4, 2011 at 3:56 AM, Dale Henrichs <dhenr...@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. Regards, Stuart
