[
http://jira.codehaus.org/browse/MRELEASE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nicolas de loof closed MRELEASE-341.
------------------------------------
Assignee: nicolas de loof
Resolution: Fixed
Fix Version/s: 2.0-beta-8
new release:stage Mojo with documentation
> support release process that use a staging repository
> -----------------------------------------------------
>
> Key: MRELEASE-341
> URL: http://jira.codehaus.org/browse/MRELEASE-341
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Affects Versions: 2.0-beta-8
> Reporter: nicolas de loof
> Assignee: nicolas de loof
> Fix For: 2.0-beta-8
>
>
> Many release process (ex: geronimo) require the release candidate to be
> exposed in a staging repository for testing, then vote from the communiity,
> and finally copy the artifact in the public repository / web site. This
> requires to run the release:perform with the final version (not a "-rc*" one).
> When the vote fails, the release manager has to rollback the project to the
> previous SNAPSHOT version. As release:perform removes all the release-related
> files (including pom backups) the release:rollback goal cannot be used for
> this.
> Geronimo solution is to copy the trunk as a "savepoint" before staging a
> release. A far better option would be to have a dedicated goal for this
> "release:stage" :
> * same features as release:perform
> * don't remove release.properties and backups
> * requires a stagingRepository parameter, to be passed as -DaltRepoLocation
> to the deploy plugin
> * detect the site:deploy goal and replace it with site:stage-deploy
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
