On Wed, 13 Aug 2008 20:52:31 Mark Hobson wrote: > For example, say I need to fix a bug in Project A 3.0 that depends on > Project B 2.0, amongst many other dependencies. I take A 3.0 and > determine that the bug is in B 2.0, so I want to update the dependency > of B in A to 2.1-SNAPSHOT. Assuming that this range was initially > declared as B[2.0,3.0), using the repository approach I would just > enable snapshot repositories for the range to resolve to my new > work-in-progress B 2.1-SNAPSHOT. This works, but it would also open > the gates for all other ranged dependencies to resolve to snapshots > too, which I certainly don't want. Whereas if ranges behaved as I've > described, then we would just update B to [2.0,2.1-SNAPSHOT) during > development and then reinstate [2.0,3.0) once the fixed B 2.1 has been > released. > I wish you would stop pointing that out ;-). I only use snapshots in local and never deploy them... if someone wants trunk then they should build it themselves... if they want to try out the latest development then take the next major version of the project which most like is alpha/beta...
Every approach that i have taken is engineered towards allowing rapid stable, reproducible change to the deliverables without too much overhead to the developers... I don't use deployed snapshots for the simple reasons that its too hard to back track... i want to very easily find out whats changed and whether rolling back or forward is the cheapest option... without tags aka releases there is just no easy way to do it... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
