> 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 - http://osgi.org. > > 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 version > > > Please comment if this does not sound natural or breaks some > well-established usage patterns. > > Thanks, > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
