On Jun 13, 2010, at 9:18 AM, Yanni Chiu wrote: > Lukas Renggli wrote: >>> Is there a way to get the bleeding edge of Pharo and a stable version of >>> Seaside? >> Not from my server, but you could setup one that builds whatever you >> need. For me, I use ... >> - ... the latest release candidate or stable release of Pharo only. >> - ... the latest package versions for code I am working on (RB, OB, >> Seaside, Magritte, Pier, ...) > > When I first set up my build server (hudson.jooshr.org), it was building the > bleeding edge of Pharo and Seaside. I've since had to back off the bleeding > edge of Pharo somewhat - I manually install new image .zip files now. I used > to run the in-image update from whatever build image was installed, but the > update often failed in headless mode, due to UI popups about deprecated > methods, among other issues. I think there's a workaround, but I've not spent > the time on it. The situation should improve now that there is a community > build server for the core at: http://rmod.lille.inria.fr/hudson/.
Yes we will have to think about the UIPopUp and nuke them. We should be able to control the UIPop only when on interactive mode. So having a exception is the way to go. > I then take the build image as the starting point to build my deliverable. I > do this build on my local machine, using another Hudson server (they're easy > to set up). In retrospect, I should have updated my initial build image much > more frequently, then I would have detected the (minor) problems with Glorp > and RFB, on PharoCore-1.1, much sooner. Note however that I had decided to > start development using PharoCore-1.0 back in January, because it was more > stable. So I had no real need to use 1.1 except to test for compatibility. I think that this was wise :) > > My plan now is to build whatever community packages that I depend on (e.g. > Glorp & RFB), continuously against the bleeding edge of Pharo. Then, whenever > I decide to update my initial build image, there should not be problems > loading community packages that I have to fix before I can run my own code. good. > So if everyone were to build/test the community packages that they depend on, > then we'd get test coverage on the most important ones. yes. We plan to include in the integration server all the metacello configuration > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
