This isn't in reply to Stephen directly since so many people have made good points.. so thanks.
I guess I'm still wonder what most people practice (or maybe not most but what's considered 'good'), in regard to the following situation... Project B will be putting out a new release based on features in Project A that Project B depends on. Project A works on their jar, runs some tests, runs things the best they can locally and then needs to have it deployed as part of the web app (Project B) so that some others in the company can look at it and examine the features etc. Later that day it's realized Project A jar needs to be modified again. So again a new version needs to go out to Project B in dev. This cycle sometimes happens quite rapidly towards the end of the development cycle. My question is "Are these quick releases typically release versions or snapshots?" To me, they seem to be snapshots, but I suppose in theory they could be considered releases with minor bug/enhancement features. It would be somewhat nice during this rapid development cycle that the version declaration in Project B would have to keep being changed. It seems like a decent(?) approach (possibly alluded to by what I've been piecing together in this thread), is that during this "busy dev time" it would be ok to change Project B's pom dependency on Project A to something like SNAPSHOT or latest release. THEN, after things settle down abit, someone makes the cool to clamp down on the dev version number dependency on Project B. I think this might be a safe approach during the time period when Project B is getting close to being 'ready' for its release to Test based on the work done by Project A. Like others have pointed out, it would then be a bad idea (I agree) to just leave the dev version of Project B to depend on snapshot of Project A. Thanks again for all the good comments so far. On Sun, Sep 14, 2008 at 10:07 AM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > You might want to either have a look at the versions-maven-plugin or > consider version ranges. > > With the versions-maven-plugin you can update a property that locks down the > version you use automatically, which can be helpful in controlling when you > get an update in your dependency. > > If you just always want the latest, you can use version ranges. > > If you make it a rule to never deploy -SNAPSHOT artifacts you can then limit > the exposure to the bleeding edge by the very separation of developers. > > i.e. > > If I am working on A & B and I do an mvn install of A 1.0.5-SNAPSHOT and B > depends on A. > > versions-maven-plugin can be configured to see the 1.0.5-SNAPSHOT on my > machine and thus I can see both dev versions. > > You are only working on B, so you will only see 1.0.4 until 1.0.5 is > released. > > The same can be achieved with version ranges but I'm never quite sure how > ranges work with -SNAPSHOT's being the latest.... i.e. is [1.0.0,) going to > include 1.0.5-SNAPSHOT? > > -Stephen > > On Sun, Sep 14, 2008 at 2:41 PM, sverhagen <[EMAIL PROTECTED]> wrote: > >> >> >> Graham Leggett wrote: >> > >> > But by doing this, project B is saying "we accept that project A may >> > break at any time, and we accept this". >> > >> > ... >> > >> > There is no "right" answer as to when this should happen, this is up to >> > the development team. But it is down to a binary choice: be on the >> > snapshot bleeding edge and access changes quickly and accept that it >> > will break randomly and without warning, or depend on a release, and you >> > get stability and controlled change. >> > >> >> Our single organisational project has a large number of modules. While >> adding single features (during Agile sprints) we change stuff in multiple >> such modules. >> Having a snapshot dependency from A on B when making corresponding changes >> between the two, for a single feature, some would argue this to be true >> Continuous Integration (thus: a good thing). >> In our environment we're for the moment happy with that. B and A are >> released shortly after each other (in that order), no problem. >> In our environment the real problems occur when A has a dependency on C as >> well, and A and C are both involved in another, concurrent feature as well. >> We've not yet found a very satisfying procedure for that one... anyone? ;-) >> -- >> View this message in context: >> http://www.nabble.com/newbie%3A-understanding-how-teams-deal-with-version-numbers-on-dependencies-%28Best-practices%29--tp19473528p19480432.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- Rick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
