On Sat, Sep 13, 2008 at 9:03 PM, Rick <[EMAIL PROTECTED]> wrote: > On Sat, Sep 13, 2008 at 4:39 PM, Graham Leggett <[EMAIL PROTECTED]> wrote: > Here's what I'm confused at though. Project A builds a jar. It needs > to be used in Project B. Ideally of course Project A should be tested > in Project B locally, but in reality (unfortunately) the dev > environment often becomes a more 'real' test. Typically the developers > of Project A will have access to Project B, so can't they just set up > the dev profile of Project B, to use the latest stable version? This > way they won't have to constantly be changing the profile for Project > B.. or is that a bad practice? Assuming some time goes by while they >
Sure, you can do this by setting a version number to 'RELEASE' to get the latest non-snapshot, but IMHO it's a bad practice in general. In any dev environment, there are lot of variables you are trying to control and the last thing you want to do is to slow down the devs by causing unexpected issues with some non-obvious change. About the only environment I could think of doing something like this is a specific continous integration profile where the system runs a test suite against the latest available dependencies *before* the devs move to it, to have a better idea whether it's safe to move to it or not. I think the old truth, "if it ain't broken, don't fix it" holds true in this case; or if the old version works, don't upgrade. Kalle
