I'm digging though some of the test deployments, and it occurs to me that for Trees, at least, the test deployment looks like it is pointing to the production url of the ERDB service, not the new test deployment of the ERDB service. This URL is configurable from the deploy.cfg file, but as far as I know we don't have an official process of changing dependent service endpoints during a test or during a migration to production. Everything still works for this minor release, because there were no new changes to the ERDB module that affect the Tree service. However, I think this is clearly a more general problem that we haven't solved. If the new version of Trees depended on a new version of the ERDB service that was not in production, how would we configure the modules to be sure that it is tested correctly? Or worse, if the new ERDB service had last minute changes that make it incompatible with the new version of Trees, but all the test deployments of Trees was still pointing to production urls, we wouldn't catch the error until *after* we pushed everything out to production. It seems like we will ultimately need to specify not just the dependent module in DEPENDENCIES, but also the version of the dependent module that is required, and then actually figure out a way to resolve these dependencies to make sure deployed modules (and test deploys) are pointing to the correct endpoints, and that these endpoints will all be compatible once we push new versions to production. I know Gavin has been thinking lately about how to approach these issues too, so we may want to bring him into these discussions as well. Working out these issues more thoroughly might be a good use of some our time during the May meeting. Any thoughts on this? Is there something I'm missing? -michael