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]
