On 05 Mar 2014, at 13:45, Damien Cassou <damien.cassou(a)gmail.com> wrote:
On Wed, Mar 5, 2014 at 1:25 PM, Stephan Eggermont
> I think the basic issue is that your development needs to happen
> in an image where you have Pier loaded with all add-ons.
actually, I think that's a good idea. Do you have a CI job that
creates a Pier 3 + all add-ons + Pillar bleeding edge images? Please
give me the url so I can do what you propose (I can help you if there
is none already).
Yes, there is. It is the CI job that builds PierAddons. It works for the stable version,
but not for the development version (that is based on Pier development and thus Pillar
development). We are currently working on fixing some add ons that fail in Pharo 3.
Nevertheless, this can only work on the short term. I can't
that tomorrow I will have to work on an image that contains many
applications that depend on Pillar and fix them all and feel
responsible for all. Currently, I know only 2 applications that depend
on Pillar (namely Pier and Marina) and a few web pages and books so
this approach could work. In the long term, only automated tests will
Yes, in the long term automated tests are better. But Pier is an existing framework where
you pull out a part of the functionality from. As the organisation on smalltakhub implies,
all projects in the group Pier belong together and are maintained together. All developers
want to make changes to Pier should keep that in mind.