[Seaside-dev] [Seaside] Build Process

[Dale Henrichs]

On 03/07/2011 09:26 AM, Lukas Renggli wrote:
> On 7 March 2011 12:26, Avi Shefi<avishefi at gmail.com>  wrote:
>> re dedicated Hudson server - not needed. I thought the current server could
>> be configured to have an artifact set under which you define a build based
>> on specific versions of packages.
>>
>> re Squeak&  Pharo automation - sounds good, probably requires a Hudson
>> plugin to make it happen.
>
> No, no plugin required. Just a line of Smalltalk code to trigger
> Metacello. Previously we didn't have Metacello builds, because ...
>
> - Metacello wouldn't allow us to load the latest code. And this was
> one of the main goals: To always have up-to-date builds with the very
> latest code, so that we know when something broke. This seems to be
> fixed nowadays.

Right:

   (ConfigurationOfSeaside30 project version: #bleedingEdge) load

will load the latest packages of Seaside as well as selected dependent 
projects: Kom and Grease.

>
> - Metacello builds were really slow compared to the traditional ones
> (which are already slow). Again this made it less useful to have a
> quick feedback loop. I don't know if this is fixed nowadays?

Metacello is faster than it used to be, but there's still room for 
improvement and room to improve:)

>
> It would be really easy to setup a different build (even if it was
> slower) that uses Monticello and that would only be triggered when the
> configuration changes. Does that make sense? What would be the code to
> trigger Metacello? What repository would need to be observed for
> changes? Doesn't Pharo already do that?

You are already doing the #bleedingEdge builds, so that would only be 
useful from the perspective that Metacello will flush out dependency 
bugs that the current build process doesn't uncover. It would be nice if 
there were continuous development builds for all of the supported Pharo 
versions (whatever the list is) and adding Squeak builds would be nice, too.

The most useful from my perspective would be a #stable build. The stable 
build could be used to produce the Pharo release artifacts: image, 
changes, on-clicks based on the configurations...Right now there is 
potential for discrepancies between the configurations and the release 
artifacts....With a hudson build using the confg there'd be no 
discrepancies.

The build would be triggered by a change to ConfigurationOfGrease or 
ConfigurationOfSeaside30. If you have some way of tracking state, then 
you would only trigger a build if the value of the #stable version changed:

   (ConfigurationOfSeaside30 project version: #stable) ~=
     previousStableVersion

Pharo builds the stable Seaside release on Pharo1.2 only which AFIAK 
isn't supported by Seaside30 yet...

Dale