commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak" <wsm...@gmail.com>
Subject Re: [vote] release commons jci RC1 as 1.0
Date Wed, 18 Apr 2007 04:41:53 GMT
On 4/15/07, Torsten Curdt <tcurdt@apache.org> wrote:
> Niall wrote:
> > A number of components have done this recently and it means
> > less chance of something going wrong after the vote passes as it
> > simply becomes a case of copying the jars/distros that have been voted
> > on rather than building a whole new set when "cutting a release".
>
> True and makes total sense. Unfortunately the maven release process
> does not really adhere to that - unless I am missing something.
>
>   mvn release:prepare -Prc
>   mvn release:perform -Prc
>
> Creates the tag and deploy to the snapshot repo.
>
>   mvn release:prepare -Prelease
>   mvn release:perform -Prelease
>
> Would be next ....but that would not match our (or the quite common)
> process of turning a RC into a release.

Instead of deploying straight to m2-ibiblio-rsync-repository, "stage"
the release somewhere else for the vote.  The two ways that work right
now are:

1. Use an alternate deployment repository configured in the pom or on
the command line.

    See http://maven.apache.org/developers/release/releasing.html
which talks about
    how to release parts of the Maven project.

2. Override <distributionManagement><repository> in your project pom.

Many projects use space under http://people.apache.org/builds/ to do
this, for example:
http://people.apache.org/builds/tiles/2.0.3/ .  This has the source
and binary distributions at the top, and then a staging repo for the
Maven artifacts, which can be merged (or just copied) into the rsynced
repo after the vote.

-- 
Wendy

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


Mime
View raw message