RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Friday, July 02, 2004 8:52 AM > To: 'Maven Developers List' > Subject: RE: when to touch changes.xml/project.xml version > RE: cvs commit: maven-plugins/java project.xml > > > > > -Original Message- > > From: Carlos Sanchez [mailto:[EMAIL PROTECTED] > > Sent: vendredi 2 juillet 2004 00:08 > > To: 'Maven Developers List' > > Subject: RE: when to touch changes.xml/project.xml version > RE: cvs commit: > > maven-plugins/java project.xml > > > > [snip] > > > > One question about SNAPSHOT, when you decide to increase version > > number should it be: > > new.version.number-SNAPSHOT > > > > This generates artifactId + version + snapshot info. > > Is this ok or should be artifactId + snapshot info? > > I personally much prefer -SNAPSHOT > > It indicates what version is being developed. Otherwise, it > cannot be guessed. Yes, I also prefer that, but I was a bit confused about SNAPSHOT (seen in docs and mails), so the recomended way is ... 1.0-SNAPSHOT ... And I'll suppose that this is supported and everything's gonna work as expected. Thanks > > Thanks > -Vincent > > > > > Thanks > > > > > > Carlos Sanchez > > A Coruña, Spain > > > > Oness Project > > http://oness.sourceforge.net > > > > > > > > > > -Vincent > > > > > > > > > > > > > - 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] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
> -Original Message- > From: Carlos Sanchez [mailto:[EMAIL PROTECTED] > Sent: vendredi 2 juillet 2004 00:08 > To: 'Maven Developers List' > Subject: RE: when to touch changes.xml/project.xml version RE: cvs commit: > maven-plugins/java project.xml > [snip] > One question about SNAPSHOT, when you decide to increase version number > should it be: > new.version.number-SNAPSHOT > > This generates artifactId + version + snapshot info. > Is this ok or should be artifactId + snapshot info? I personally much prefer -SNAPSHOT It indicates what version is being developed. Otherwise, it cannot be guessed. Thanks -Vincent > > Thanks > > > Carlos Sanchez > A Coruña, Spain > > Oness Project > http://oness.sourceforge.net > > > > > > -Vincent > > > > > > - > > 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]
RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
> I agree, I don't like doing things twice ;) > > One question about SNAPSHOT, when you decide to increase version number > should it be: > new.version.number-SNAPSHOT > > This generates artifactId + version + snapshot info. > Is this ok or should be artifactId + snapshot info? > During the development you should set the version to next.release + snapshot Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 01, 2004 9:52 PM > To: 'Maven Developers List' > Subject: RE: when to touch changes.xml/project.xml version > RE: cvs commit: maven-plugins/java project.xml > > > > > -Original Message- > > From: Maczka Michal [mailto:[EMAIL PROTECTED] > > Sent: jeudi 1 juillet 2004 09:52 > > To: 'Maven Developers List' > > Subject: RE: when to touch changes.xml/project.xml version > RE: cvs commit: > > maven-plugins/java project.xml > > > > > > > > > -Original Message- > > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, July 01, 2004 7:46 AM > > > To: 'Maven Developers List' > > > Subject: RE: when to touch changes.xml/project.xml version RE: cvs > > > commit: maven-plugins/java project.xml > > > > > > > > > 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. > > > > > +1 > > > > Simple and clear rule. > > > > I would add that new entry in changes.xml file must be added to > > explain what already happen and why the version was bumped. > > Even (I think it is not good idea) if somebody will find some > > information in this file irrelevant for end users - they > still can be > > removed during the release process. > > I don't quite agree on this last point... :-) The point of > the changes.xml file over the changelog report generation is > precisely that we are filtering what is useful for end users to know. > > If a plugin developer want to know what was the reason for > such and such modification, he can consult the CVS commit > comments and diffs. I agree, I don't like doing things twice ;) One question about SNAPSHOT, when you decide to increase version number should it be: new.version.number-SNAPSHOT This generates artifactId + version + snapshot info. Is this ok or should be artifactId + snapshot info? Thanks Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net > > -Vincent > > > - > 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]
RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
> -Original Message- > From: Maczka Michal [mailto:[EMAIL PROTECTED] > Sent: jeudi 1 juillet 2004 09:52 > To: 'Maven Developers List' > Subject: RE: when to touch changes.xml/project.xml version RE: cvs commit: > maven-plugins/java project.xml > > > > > -Original Message- > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 01, 2004 7:46 AM > > To: 'Maven Developers List' > > Subject: RE: when to touch changes.xml/project.xml version RE: cvs > > commit: maven-plugins/java project.xml > > > > > > 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. > > > +1 > > Simple and clear rule. > > I would add that new entry in changes.xml file must be added to explain > what > already happen and why the version was bumped. > Even (I think it is not good idea) if somebody will find some information > in > this file irrelevant for > end users - they still can be removed during the release process. I don't quite agree on this last point... :-) The point of the changes.xml file over the changelog report generation is precisely that we are filtering what is useful for end users to know. If a plugin developer want to know what was the reason for such and such modification, he can consult the CVS commit comments and diffs. -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
Yeah, you're right - I got a bit side tracked from the original point. I was only thinking that project.xml of a plugin doesn't need to change when the plugin-test is modified as the plugin-test is a separate project altogether. I definitely think changes.xml only needs to have user-needs-to-know, hopefully non-technical, changes added though, regardless of what in the project is changing. Cheers, Brett Quoting Maczka Michal <[EMAIL PROTECTED]>: > > > > -Original Message- > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 01, 2004 7:46 AM > > To: 'Maven Developers List' > > Subject: RE: when to touch changes.xml/project.xml version RE: cvs > > commit: maven-plugins/java project.xml > > > > > > 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. > > > +1 > > Simple and clear rule. > > I would add that new entry in changes.xml file must be added to explain what > already happen and why the version was bumped. > Even (I think it is not good idea) if somebody will find some information in > this file irrelevant for > end users - they still can be removed during the release process. > > Michal > > - > 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]
RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 01, 2004 7:46 AM > To: 'Maven Developers List' > Subject: RE: when to touch changes.xml/project.xml version RE: cvs > commit: maven-plugins/java project.xml > > > 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. > +1 Simple and clear rule. I would add that new entry in changes.xml file must be added to explain what already happen and why the version was bumped. Even (I think it is not good idea) if somebody will find some information in this file irrelevant for end users - they still can be removed during the release process. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
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]
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]
Re: when to touch changes.xml/project.xml version RE: cvs commit: maven-plugins/java project.xml
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]
