[Seaside-dev] [Seaside] Build Process
Dale Henrichs
dhenrich at vmware.com
Tue Mar 8 17:45:23 UTC 2011
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
More information about the seaside-dev
mailing list