I guess we need to separate 3rd party dependencies and internal dependencies.
In general you do not want to depend on a -SNAPSHOT version of a third party dependency... for example in between releases, there is no way I'd switch from log4j-1.2.15 to log4j-1.2.16-SNAPSHOT ___unless___ there was a bug in 1.2.15 that was affecting my code, in which case I might switch to the -SNAPSHOT until either log4j releases, or I need to release at which point I would also do a release of log4j-1.2.16-mycompany-01 However, if these are internal dependencies, chances are that you actually do want the -SNAPSHOT dependency... so if i'm working on foobar-optional 2.3-SNAPSHOT I will depend on foobar-core 2.3-SNAPSHOT also... now there's this quirky feature that I'm adding to foobar-optional, and the guys working on foobar-core are great at breaking their build... so what I do in that case is I lock my -SNAPSHOT dependency on foobar-core to 2.3-20090422.181944-5 because that one is working, then I add my feature and when I'm finished I restore back to a regular -SNAPSHOT and start worrying about integrating with the changes that they made to foobar-core -Stephen 2009/4/22 Michael Hüttermann <[email protected]> > hmm how does that help between releases? You need to adress stable, > labeled versions of artifacts .. so in my feeling you aren't allowed to > use any snapshot version at all .. ? > > Michael > > > > I think (actually I hope) he's talking about between releases. > > > > trunk might be moving rapidly, so you fork a branch to work on a > > feature... > > you don't want the changes to the artifacts from trunk screwing with your > > build until you are ready to merge the branch back to trunk... > > > > If he's got some other plan then I'd advise him against using timestamp > > snapshots for such a crazy plan (which I'm sure he will share in an > effort > > to prove that it's not crazy) > > > > -Stephen > >
