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."