June 13, 2010
7:30 a.m.
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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project