commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [releasing] SVN Tag creeated by maven
Date Wed, 13 May 2009 19:17:52 GMT
On 13/05/2009, Mark Struberg <struberg@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 <dan@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-unsubscribe@commons.apache.org
>  > For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message