On 13/05/2009, Dan Fabulich <d...@fabulich.com> wrote: > sebb wrote: > > > > However, if the directory names within the archives contain the -RC2 > > suffix, then that is a different matter. Maybe a Maven expert can give > > advice here on how to work with immutable tags? > > > > I consider myself reasonably expert with Maven, and my opinion is that > Maven's release process is entirely wrong and does not embody a best > practice. :-( > > The problem here is that the source code (the pom.xml file) contains the > path to the source code in subversion. So if you tag the RC as > DBUTILS_1_2_RC1 then the source code includes "RC1".
Is it possible to create a tag with RC1, but leave the POM with DBUTILS_1_2? I think that might solve at least some of the problems. > If you then later copy > that tag to "DBUTILS_1_2" the source code will still say "RC1". > > Since you can't modify the source code after the vote, your best bet is to > create the RC with the final location for the tag and delete/re-tag for each > RC. :-( > > IMO, it's entirely wrong for the pom.xml source code to describe the > location of the source code. The reason Maven wants this information there > is so when it goes to deploy (either for snapshots or releases) the deployed > .pom file in the Maven repository will contain a link to the source code. > > That feature should be implemented by inserting the source link in the > deployed .pom file at deploy time. (It should be auto-detected, or read > from some non-checked-in location or manually specified at that time.) Sounds good. > At a more philosophical level, the only reason Maven *has* a release plugin > is because its release philosophy is wrong: the Maven philosophy is to make > changes to the source code at release time, which is fundamentally a bad > idea which I hope we can fix some day. > > -Dan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
