maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCallum <>
Subject Re: Mercury Version Ranges
Date Wed, 13 Aug 2008 21:43:07 GMT
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 

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message