Brett, Why not take the easy route, that is, if not already bumped then bump the plugin version for whatever change you're bringing. It just won't be released before there are any significant changes to it.
-Vincent > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: jeudi 1 juillet 2004 07:39 > To: Maven Developers List > Subject: Re: when to touch changes.xml/project.xml version RE: cvs commit: > maven-plugins/java project.xml > > It's a tough call. It may or may not change the resultant artifact (eg if > you > change plugin.jelly's formatting...), so its better to err on the side of > incrementing it. > > I don't usually reorganise those things for the sake of it though - its > usually > at the same time as doing other changes so its irrelevant. > > Personally, I'd prefer not to have the version in the CVS version of the > POM at > all (or ignore it) and insert it into the deployed one at release time. > That way > its not a problem :) > > - Brett > > Quoting Dion Gillard <[EMAIL PROTECTED]>: > > > On Thu, 1 Jul 2004 12:49:50 +1000, Brett Porter <[EMAIL PROTECTED]> > wrote: > > > > > So in summary I think: > > > - bump project.xml version whenever the source code/meta > data/dependencies > > > change that will affect the resultant artifact > > > > So in this case, extrapolating onto Maven, fixing junit test cases > > doesn't bump project.xml? Ditto code cleanup (checkstyle, imports) > > etc. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
