[Pharo-project] Hudson build for Seaside too?
dhenrich at vmware.com
Mon Feb 7 04:22:09 CET 2011
On Feb 6, 2011, at 12:05 PM, Marcus Denker wrote:
> On Feb 4, 2011, at 4:13 PM, Dale Henrichs wrote:
>> Since I seem to be on a symbolic version kick today, may I suggest that you use symbolic versions for Hudson:
>> Gofer new
>> squeaksource: 'MetacelloRepository';
>> package: 'ConfigurationOfSeaside30';
>> ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load.
>> when you get a chance ...
>> the above expression can be used for all of your Hudson builds regardless of pharo version.
> use the same, but it loads then a different *stable* for each version?
There _could_ be a different version for each platform, so by using #stable you'll always get the version that the developers expect to work.
>> ((Smalltalk at: #ConfigurationOfSeaside30) project version: #unstable) load.
> would load the latest code into e.g. 1.3?
My opinion is that you should use the #stable symbolic version for Pharo1.3 as well. The rule should be:
- the #stable version is the version that the developers recommend to use on a particular platform/platform version
If no #stable version is defined, then the developers haven't finished their porting job yet.
Just because the underlying platform version may be unstable doesn't mean that all of the configurations targeting Pharo1.3 should define another symbolic version for that means "use me on Pharo1.3" ... Anyone using an unstable platform must be aware that at any point in time there may be a change to the underlying system that may break other software in weird and wonderful ways, so the #stable symbolic version for an unstable version means that the version is the best that the developer has for that version....stable is the moral equivalent of latest version ....
With that in mind, I think that you should modify the script to the following:
((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load.
on: (Smalltalk at: #MetacelloVersionDoesNotExistError)
do: [:ex | Transcript show: 'load skipped because no #stable version available'].
Then if I know (for example) that Seaside3.0 doesn't work on Pharo1.3, I can specify that there is no #stable version for 1.3 and you won't even try to load the code let alone run the tests and have a bunch of failures... of course it also is a clear indication to other folks wondering if Seaside3.0 works on Pharo1.3 that it's not ready yet ...
So to repeat, if there is a #stable version defined for Pharo1.3, then it is expected to work modulo any recent changes to the pharo core ... no #stable version defined means that the developers don't have a version ready to run yet.
More information about the Pharo-project