Version ranges seem to totally break reproducibility of released builds.
Personally, I'd like to see these eliminated from Maven altogether and replaced with a separate version compatibility field that indicates which versions of a dependency you are compatible with but still have a specific version that you declare: ... <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>2.5.5</version> <compatibility>[2.5,3.0-!)</compatibility> </dependency> ... This would ensure reproducibility while providing higher value version information that could then be used within metadata and leveraged by containers such as OSGI. Pete -----Original Message----- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Wednesday, April 08, 2009 3:16 AM To: Maven Users List Cc: Maven Users List Subject: Re: LATEST and RELEASE release version management sounds like you want version ranges [1.0,2.0-!) Sent from my [rhymes with myPod] ;-) On 8 Apr 2009, at 01:39, Tim <che...@gmail.com> wrote: > http://jira.codehaus.org/browse/MNG-4089 > I need to read over the bug that was linked as a duplicate more > closely but > I don't think it's the same thing. > What I asked for was the same as what you said with 1.0-LATEST. > Doing something like that or 1.0-RELEASE would actually be very > beneficial > to people that know that minor releases won't break backwards > compatibility > but will allow for more features without having to keep changing > versions. > > On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox > <bri...@reply.infinity.nu>wrote: > >> Having the release plugin translate these values at release time >> _before_ the validation build and tag is the only sane way to use >> them. >> I currently have never use them because they aren't repeatable. >> >> >> >> From: Hayes, Peter [mailto:peter.ha...@fmr.com] >> Sent: Monday, April 06, 2009 12:12 PM >> To: Maven Users List >> Subject: RE: LATEST and RELEASE release version management >> >> >> >> Graham Leggett wrote: >> >>> Having said that, it makes no sense to have the release plugin care >>> about LATEST, because by definition, building against LATEST isn't >>> repeatable, and in order for there to be a release, you need the >>> build >>> to be repeatable. >> >> I think this does impact the release plugin as it could offer the >> ability to resolve the LATEST version at release time. These builds >> would be reproducible because the release plugin tags the poms during >> the release process. >> >> I think what you're saying is that the build prior to the release >> build >> is not guaranteed to have the same dependent artifacts as the release >> build. I care about the release build being reproducible. >> >> Pete >> >> > > > -- > > Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html > > > - "A computer once beat me at chess, but it was no match for me at > kick > boxing." --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
