On Thu, 9 Oct 2003 12:17 am, Florin Vancea wrote: > If I may say something before it's too late: Maybe there is a need for a > LATEST on each (or on several) branch (es). > > Something like > > <dependency> > <groupId>log4j</groupId> > <artifactId>log4j</artifactId> > <version>LATEST</version> > </dependency> > > should get the latest-and-gratest, but something like > > <dependency> > <groupId>log4j</groupId> > <artifactId>log4j</artifactId> > <version>1.LATEST</version> > </dependency> > > should use the latest version available that still has the version with > prefix "1." > > Just a thought...
I think it is a good throught but ... I think that it may be a beta idea to formalize a version-ing standard before you do this. For example one project may assume that anything compiled against 1.1 will work in 1.2 (ie minor versions represent forward compatible changes). Another project may assume that micro versions represent forward compatability (ie 1.1.2 is compatible with 1.1.1 or 1.1). That would make dependencys very close to JDK "optional packages"/"extensions" ala (except for no separation between implementation and specification). http://spice.sourceforge.net/extension/ http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html Alternatively you could specify version resolution scheme in the dependency declaration via something like <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.1</version> <version-resolution-policy>extension</version-resolution-policy> </dependency> -- Cheers, Peter Donald *---------------------------------------------* | "The only way to discover the limits of the | | possible is to go beyond them into the | | impossible." -Arthur C. Clarke | *---------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
