On 13/05/2009, Mark Struberg <strub...@yahoo.de> wrote: > > > So if you tag the RC as DBUTILS_1_2_RC1 then the > > source code includes "RC1". If you then later copy that tag to > "DBUTILS_1_2" > > the source code will still say "RC1". > > > Sorry Dan, there are a lot things missing in mavens release process, but this > very thing is imho not a problem with maven but with the weirdness of SVN > handling tags. If you make a svn:copy, then you _will_ create_a_new_tag_!
What is weird about that? Creating a copy is the whole point of it; we just want to make sure that the tagged copy always represents the same code. > So pom.xml still contains exactly that what has been released, and not only > pom.xml, but _ALL_ release artifacts e.g. the sources.tar.gz, etc. Renaming > tags, moving tags etc is essentially a no-no if you don't perform a build > from that exact location afterwards. SVN guaranties atomic operations - at > least _almost_ always. And I've seen a lot of weirdness in my last 20 years > of using SCMs where this 'almost' did matter a lot ;) If you have to make > sure 100%, then you have to build from the exact location. > > What's wrong with the maven-staging? You tag as if you do a release (with > exact that tag in SVN and pom.xml) but the results will not be deployed to > the final repo but only to a staging repo. Maybe I only missed that part of > the discussion, sorry for the noise then. > LieGrue, > strub > > > ----- Ursprüngliche Mail ---- > > Von: Dan Fabulich <d...@fabulich.com> > > An: Commons Developers List <dev@commons.apache.org> > > Gesendet: Mittwoch, den 13. Mai 2009, 20:47:34 Uhr > > Betreff: Re: [releasing] SVN Tag creeated by maven > > > > > 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". 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.) > > > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
