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 03:15:30 GMT
> 3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include
> 2.1-alpha-1, etc
Should most definitely not inlude 2.1-alpha-1 consider this scenario...

module Z released as 2.X 
a dependent module Y specifies X [2,3)
you now make a breaking change and release the alpha version of Z 3.0-alpha-1 
and BAM module Y is using it when it explicitly said I only want major 
version 2

On Wed, 13 Aug 2008 12:51:17 Oleg Gusakov wrote:
> Working on Mercury I faced the necessity to use some standard definition
> of a "version range", so I took OSGi definition: OSGi core specs 4.1,
> page 39 in April-2007 PDF available on OSGi site -
> Some interesting ramifications for Maven users:
> 1). Declaration 1.2.3 means any version X, greater or equal to 1.2.3:
> 1.2.3 <= X. We are used to a soft version of that in Maven builds -
> version can be replaced by a more applicable dependency. But spec states
> ANY version: i.e. found in any scanned repository.
i always use ranges to do otherwise IMO is just asking for trouble ;-)

> 2). I strongly feel that failing any explicit ranges, containing
> snapshots is a good thing. For instance, dependency declaration
> 1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like
> [1.2-SNAPSHOT,2.0) or [1.0,1.2-SNAPSHOT)
if you don't allow 1.2-SNAPSHOT how do you actually include them
lets assume that 1-SNAPSHOT < 1-alpha < 1-beta < 1 < 1.1 < 1.1.1
and i say [1,2) then -SNAPSHOT, alpha and beta will not match

I always start my versions at 1.1, 2.1, 3.1 for the lower bound... otherwise 
you end up with not being able to use the first snapshot of a new major 
version in a range
And I use the  -! syntax for the upper bound which stops the next major 
versions first snapshot from creeping into a range for the previous major 
> Please comment if this does not sound natural or breaks some
> well-established usage patterns.
> Thanks,
> Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Michael McCallum
Enterprise Engineer

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

View raw message